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Abstract 


This  thesis  introduces  a  new  model  for  distributed  computation  in  asynchronous 
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hierarchical  correctness  proofs  of  distributed  algorithms.  This  thesis  defines  the  input- 
output  automaton  model,  and  presents  an  interesting  example  of  how  this  model  can 
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I 


A  major  obstacle  to  program  in  the  field  of  distributed  computation  is  that  many  of  the 
important  algorithms,  especially  communications  algorithms,  seem  to  be  too  complex 
for  rigorous  understanding  Although  tha  dssigners  of  thasa  algorithms  are  often  able 
to  convey  an  intuitive  understanding  of  how  their  algorithms  work,  it  is  often  difficult  to 
make  this  intuition  formal  and  precise.  When  these  algorithms  are  rigorously  analysed, 
the  work  is  generally  carried  out  at  a  very  low  level  of  abstraction,  involving  mnaaigie 
and  local  process  variables.  Reasoning  precisely  about  the  interaction  between  these 
messages  and  variables  can  be  extremely  difficult,  and  the  resulting  proofs  of  correctness 
are  generally  quite  difficult  to  understand. 

An  indication  that  the  situation  is  not  completely  hopeless  is  the  fact  that  the 
designers  arc  able  to  give  high-level,  although  informal,  descriptions  of  the  key  ideas 
behind  their  algorithms.  For  instance,  the  distributed  minimum  spanning  tres  algo* 
rithm  of  [GHS83]  can  be  interpreted  as  several  familiar  manipulations  of  a  graph.  What 
is  needed  is  a  way  of  formalising  these  high-level  ideas,  and  incorporating  them  into  a 
proof  of  the  detailed  algorithm’s  correctness. 

One  promising  approach  is  to  begin  by  constructing  a  high-level  description  of 
the  algorithm.  This  description  could  iittlf  be  an  algorithm  in  which  high-level  data 
structures  (such  as  graphs)  serve  as  states,  and  process  actions  manipulate  these  data 
structures.  This  algorithm  could  then  be  proven  correct  using  rigorous  versions  of  the 
high-level,  intuitive  arguments  given  by  the  algorithm’s  dssigners.  Successive  refine¬ 
ments  of  this  algorithm  could  then  be  defined  at  successively  lower  levels  of  detail,  and 
each  shown  (rigorously)  to  simulate  the  preceding  algorithm.  Ideally,  this  approach 
would  allow  us  to  use  in  the  proof  of  simulation  any  property  that  has  already  been 
proven  for  preceding  levels.  In  this  way,  the  high-level  intuition  used  to  explain  the 
algorithm  would  become  part  of  a  rigorous  proof  of  the  full  algorithm’s  correctness. 

Two  years  ago,  we  began  to  consider  this  approach  for  a  fairly  simple  but  interesting 
algorithm  for  resource  allocation  in  an  asynchronous  network,  an  algorithm  originally 


suggested  by  Schonhage  in  [Sch80].  Correctness  conditions  for  this  resource  arbitration 
problem  include  both  safety  and  liveness  conditions:1  the  mutual  exclusion  condition 
that  at  most  one  user  is  using  the  resource  at  any  given  time;  and  the  no  lockout 
condition  that  if  every  user  holding  the  resource  eventually  returns  the  resource  to  the 
arbiter,  then  the  arbiter  will  eventually  grant  the  resource  to  every  requesting  user.  The 
algorithm  can  be  described  at  three  levels  of  abstraction.  At  the  top  level  is  a  simple, 
set-theoretic  statement  of  the  problem,  itself  described  as  an  algorithm.  At  the  second 
level  is  a  graph-theoretic  description  of  the  arbiter,  and  how  it  moves  the  resource 
around  the  network.  At  the  third  and  lowest  level  is  a  distributed  implementation  of 
the  arbiter,  describing  in  terms  of  messages  and  local  process  variables  the  protocol 
individual  processors  must  follow. 

It  soon  became  apparent,  however,  that  traditional  models  and  proof  techniques  (see 
[OG76],  [LS84b],  and  [Hoa85],  for  example)  are  not  adequate  to  describe  interesting 
aspects  of  the  problem  statement,  algorithm,  and  correctness  proofs.  In  particular, 
while  the  problem  seems  most  naturally  formulated  in  terms  of  the  game-theoretic 
interaction  between  the  users  of  the  arbiter  and  the  arbiter  itself,  these  models  require 
that  the  problem  be  formulated  in  terms  of  system  states,  and  do  not  capture  this 
game-theoretic  aspect  of  the  problem  in  a  natural  way.  Furthermore,  the  interaction 
between  the  users  and  the  arbiter  clearly  distinguishes  the  arbiter’s  input  actions  from 
its  output  actions.  Input  to  the  arbiter  (a  request  for  the  resource)  can  occur  at  any 
time,  regardless  of  whether  the  arbiter  is  in  a  position  to  grant  the  resource.  Output 
(the  granting  of  requests)  occurs  only  under  the  control  of  the  arbiter.  This  notion 
of  control,  the  notion  that  one  system  component  may  completely  determine  when  a 
particular  action  is  performed,  is  not  easily  expressed  in  these  models.  We  note  that 
satisfaction  of  the  no  lockout  condition  requires  that  the  arbiter  be  given  “fair  turns” 
to  produce  output,  rather  than  simply  being  overwhelmed  by  a  flood  of  input.  The 
ability  to  express  this  notion  of  “fair  turns”  depends  heavily  on  the  ability  to  express 
the  notion  of  one  process  controlling  the  performance  of  an  action. 

We  were  therefore  led  to  the  development  of  a  new  model  of  distributed  compu¬ 
tation  in  asynchronous  systems,  the  input-output  automaton.  This  model  is  based  on 
(possibly  infinite-state)  nondeterministic  automata.  Automaton  transitions  are  labeled 
with  the  names  of  process  actions  they  represent.  These  actions  are  partitioned  into 
sets  of  input  and  output  actions,  as  well  as  internal  actions  representing  internal  pro¬ 
cess  actions.  Input  actions  have  the  unique  property  of  being  enabled  from  every  state; 
that  is,  for  every  input  action  there  is  a  transition  labeled  with  this  action  from  every 
state.  In  other  words,  the  system  must  be  able  to  accept  any  input  at  any  time.  Thus, 

1  Informally,  properties  required  of  a  program  can  be  partitioned  into  ss/cty  properties  and  iteeneee 
properties.  A  safety  property  (snch  as  mntnal  exclusion  (Dij65|)  says  that  nothing  'bad*  will  ever  hap¬ 
pen,  and  a  liveness  property  (snch  as  termination)  says  that  something  'good*  will  eventually  happen. 
Alternatively,  safety  properties  describe  allowed  behavior,  and  liveness  properties  describe  required  be¬ 
havior.  Alpern  and  Schneider  give  formal  definitions  of  safety  and  liveness  in  [ASM]  in  terms  of  Buchi 
automata. 


a  very  strong  distinction  is  made  between  actions  locally-controlled  by  the  system  (out¬ 
put  and  internal  actions)  and  actions  controlled  by  the  system's  external  environment 
(input  actions).  This  distinction  captures  the  game-theoretic  interaction  between  the 
system  and  its  environment  alluded  to  above,  and  gives  our  model  an  event-driven 
flavor  characteristic  of  many  asynchronous  distributed  algorithms. 

In  order  to  construct  models  of  complex  systems  from  models  of  simpler  system 
components,  we  define  a  simple  notion  of  automaton  composition.  Loosely  speaking, 
the  composition  of  a  collection  of  automata  is  their  Cartesian  product,  with  a  state  of 
the  composition  being  a  tuple  of  states  from  the  component  automata,  one  from  each 
component.  In  order  to  model  communication,  we  require  that  automata  synchronize 
the  performance  of  common  (shared)  actions.  If  *  is  an  output  action  of  A  and  an 
input  action  of  £,  then  performance  of  x  by  both  automata  models  communication 
from  A  to  B.  With  simple  syntactic  restrictions  on  the  composition  of  automata,  we 
ensure  that  composition  preserves  the  notion  of  control  mentioned  above:  No  system 
component  may  block  the  performance  of  an  output  action  by  any  other  component. 

Since  automata  are  able  to  receive  every  input  in  every  state,  it  is  possible  for  an 
automaton  to  be  flooded  with  input  without  having  the  opportunity  to  perform  actions 
required  in  response  to  the  input  received.  The  satisfaction  of  most  interesting  liveness 
conditions,  however,  requires  that  this  does  not  happen.  The  notion  of  fair  computation 
therefore  plays  a  fundamental  role  in  our  model.  Informally,  a  computation  of  a  system 
is  said  to  be  fair  if  every  system  component  is  always  eventually  given  the  chance  to 
take  a  step.  Since  an  automaton  may  model  an  entire  system  as  well  as  a  single 
system  component,  it  is  necessary  to  retain  certain  information  about  the  structure  of 
the  system  being  modeled.  In  particular,  it  is  necessary  to  retain  information  about 
which  actions  are  controlled  by  the  same  system  component.  With  this  information  it  is 
possible  to  determine  from  a  given  system  behavior  whether  each  system  component  has 
been  given  the  chance  to  make  computational  progress  infinitely  often.  We  therefore 
associate  with  every  automaton  a  partition  of  its  locally-controlled  actions  (i.e.,  its 
internal  and  output  actions).  The  interpretation  of  this  partition  is  that  each  class 
consists  of  the  locally-controlled  actions  of  one  system  component.  With  this  partition, 
we  are  able  to  define  a  simple  notion  of  fair  computation  in  our  model. 

Since  our  model  concentrates  on  the  input-output  interaction  between  a  system 
and  its  environment  (rather  than  system  states),  our  notion  of  a  problem  to  be  solved 
is  a  collection  of  system  behaviors  (sequences  of  input  and  output  actions)  considered 
acceptable  (rather  than  conditions  on  system  states).  An  automaton  may  be  considered 
a  solution  to  such  a  problem  if  every  behavior  exhibited  by  the  automaton  is  contained 
in  this  set  of  acceptable  behaviors.  The  automaton  solves  the  problem  in  the  sense 
that  any  correctness  condition  satisfied  by  each  behavior  in  this  set  is  satisfied  by  each 
behavior  of  the  automaton.  As  previously  mentioned,  however,  fair  computation  is 
crucial  to  the  satisfaction  of  most  interesting  liveness  conditions.  We  therefore  require 
only  that  the  fair  behaviors  of  an  automaton  solving  the  problem  be  contained  in  the 
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set  of  acceptable  behaviors.  We  note  that  it  is  easy  to  fall  into  trivial  correctness 
definitions,  allowing  trivial  or  uninteresting  solutions  to  a  problem.  Our  condition 
that  an  automaton  be  required  to  accept  any  input  in  any  state,  together  with  our 
notion  of  fairness,  avoids  this  problem.  The  requirement  that  input  be  constantly 
enabled  ensures  that  our  solutions  are  able  to  respond  to  all  patterns  of  input.  The 
use  of  fairness  ensures  that  the  correctness  of  an  solution  will  be  judged  only  by  thoee 
behaviors  in  which  the  system  is  actually  given  the  chance  to  make  progress. 

Our  simple  correctness  condition,  the  requirement  that  the  fair  behaviors  of  an 
automaton  be  contained  in  some  set  of  acceptable  behaviors,  is  not  a  new  style  of  cor¬ 
rectness  conditions.  It  can  be  found,  for  instance,  in  the  work  of  Lynch  and  Fischer 
in  [LF8I],  and  is  similar  to  Hoare’s  notion  of  specification  satisfaction  in  [Hoa85].  The 
simplicity  of  such  correctness  conditions  do,  however,  lend  a  uniform  structure  to  cor¬ 
rectness  proofs  in  our  model.  Recall  that  our  notion  of  a  well-structured  correctness 
proof  involves  a  sequence  of  models  M\,. . . ,  Mn,  each  modeling  an  algorithm  at  succes¬ 
sively  lower  levels  of  detail.  The  proof  of  the  algorithm's  correctness  involves  showing 
that  each  model  “simulates’’  the  previous  model  in  the  sequence.  That  is,  that  the  set 
of  (fair)  behaviors  exhibited  by  M,  axe  contained  in  the  set  of  (fair)  behaviors  exhibited 
by  Mi- 1.  In  this  sense,  each  model  Af<_i  determines  a  problem  that  the  model  M,-  is 
required  to  satisfy.  The  problem  of  showing  that  “simulates”  M,_i  is  therefore  the 
problem  of  showing  that  Mi  solves  the  problem  determined  by  M<_  j.  As  an  aid  in  doing 
so,  we  develop  the  notion  of  possibilities  mappings  that  enable  us  to  relate  behaviors  of 
one  automaton  to  another. 

We  note  that  our  model  may  be  considered  a  special  case  of  other  models  such  as 
Milner’s  CCS  and  Hoare’s  CSP  (see  [Mi!80]  and  [Hoa85]).  Neither  of  these  models, 
however,  is  entirely  suitable  for  our  purposes.  In  the  first  place,  although  Milner  has 
found  them  to  be  mathematically  superfluous  in  CCS,  we  find  the  notion  of  a  process 
state  a  convenient  descriptive  tool  when  describing  algorithms.  More  important,  how¬ 
ever,  is  the  fact  that  fairness  is  difficult  to  express  in  CCS.  Notions  of  fairness  that 
have  been  studied  in  connection  with  CCS  can  be  classified  as  either  weak  fairness  or 
strong  fairness  (see  [CS84],  [Par85],  and  [Fra86]).  Weak  fairness  requires  that  if  an 
action  x  is  continuously  enabled,  then  it  must  be  performed  infinitely  often.  Strong 
fairness,  on  the  other  hand,  requires  that  r  be  performed  infinitely  often  even  if  it  is 
enabled  only  infinitely  often.  These  notions  of  fairness,  however,  are  not  satisfactory  in 
event-driven  systems.  In  such  a  system,  for  example,  a  process  is  always  able  to  accept 
interrupts,  but  should  not  be  required  to  interrupt  itself  unless  some  external  source 
requests  -he  interrupt.  The  problem  is  again  the  notion  of  control  discussed  above. 
There  is  no  notion  in  CCS  of  an  interface  between  processes  from  which  we  can  deduce 
which  which  process  controls  the  performance  of  a  given  action.  By  making  a  clear 
distinction  between  input  and  output  actions,  and  by  restricting  ourselves  to  a  simple 
notion  of  composition,  we  find  that  fairness  is  very  simple  to  describe  in  our  model. 

Similar  comments  can  also  be  made  for  CSP  with  respect  to  fairness  (see  [KdR83], 
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(Rei84|,  and  (Fra86j).  In  fact,  CSP  further  complicates  the  problem  by  identifying 
a  process  with  (among  other  things)  all  finite  behaviors  of  the  process.  Since  it  is 
impossible  to  deduce  the  infinite  behavior  of  a  process  from  its  finite  behaviors,  CSP 
precludes  the  study  of  infinitary  properties  such  as  fairness  without  extending  the 
semantics  of  a  CSP  process. 

We  note  further  that  the  complexity  of  the  operations  defined  in  CSP  dooms  the 
language  to  a  complex  semantics,  making  reasoning  about  systems  of  processes  unin¬ 
tuitive  and  cumbersome.  Reading  between  the  lines  of  Hoare’s  book  [Hoa85],  it  seems 
that  Hoare  himself  would  prefer  to  retain  for  nondeterministic  processes  the  automata- 
theoretic  (trace- theoretic1)  semantics  he  develops  for  deterministic  processes.  However, 
the  first  nondeterministic  operation  introduced  by  Hoare  is  the  nondeterministic  OR,  n, 
an  operation  combining  two  processes  P  and  Q  to  form  a  process  PnQ  that  nonde- 
terminiatically  chooses  (itself)  to  behave  either  like  P  or  Q.  A  second  operation,  □, 
combines  P  and  Q  to  form  a  process  POQ  allowing  the  environment  to  determine 
whether  POQ  behaves  like  P  or  Q.  Both  PnQ  and  POQ  have  the  same  traces  (since 
each  behaves  either  like  P  or  Q),  but  differ  subtly  in  the  fact  that  the  environment 
has  no  control  or  knowledge  of  the  choice  PnQ  makes  between  P  and  Q.  Thus,  it  is 
possible  for  P  (~1  Q  and  POQ  to  be  placed  in  an  environment  offering  an  action  ir  as 
input,  causing  P  n  Q  to  deadlock  while  POQ  does  not.  This  forces  Hoare  to  make  his 
first  break  from  the  trace-theoretic  semantics  of  deterministic  processes  and  define  the 
notion  of  a  refusal,  a  set  of  actions  a  process  might  refuse  to  perform.  In  our  model, 
however,  due  to  the  unique  property  of  input  actions,  a  process  will  not  block  if  its 
environment  offers  *  as  input.  Thus,  by  suitably  restricting  our  model,  we  are  able  to 
retain  the  intuitive,  mathematically-tractable  semantics  of  automata. 

We  note  that  there  are  systems  of  processes  that  can  not  be  expressed  in  our  model. 
Clearly,  one  such  example  is  a  system  in  which  one  process  can  block  the  progress  of 
another  as  in  CSP.  These  omissions,  however,  are  the  result  of  deliberate  decisions, 
since,  for  example,  it  would  be  easy  to  define  a  notion  of  composition  that  allows  us 
to  express  the  process  blocking  of  CSP.  The  simplicity  of  our  model  and  its  esse  of  use 
are  the  result  of  a  careful  limitation  of  its  scope.  Our  experience  has  been  that  our 
model  is  sufficiently  general  to  allow  description  of  a  significant  number  of  interesting 
systems.  We  note  that  our  model  has  already  been  found  expressive  enough  to  de¬ 
scribe  work  in  network  algorithms  (see  [LLW87]  and  the  third  chapter  of  this  thesis), 
concurrency  control  algorithms  (see  [LM86],  [HLMW87],  [FLMW87],  and  [GL87]),  mu¬ 
tual  exclusion  algorithms  (see  [Wel87j),  hardware  register  algorithms  (see  [Blo87]),  and 
dataflow  computation  (see  [Lyn86]).  Furthermore,  in  many  of  these  papers  our  model 
has  been  found  to  be  extremely  useful  when  identifying  the  interface  between  system 
components,  and  discovering  a  system’s  natural  decomposition. 

Just  as  popular  models  of  computation  do  not  seem  appropriate  for  our  work, 
popular  proof  techniques  also  seem  inappropriate.  For  example,  “Hoare  logics”  are 


3  A  trace  is  a  sequence  of  actions  performed  by  a  system  or  process. 


a  well-known  method  for  proving  that  programs  satisfy  partial  correctness  assertions. 
Loosely  speaking,  a  partial  correctness  assertion  is  a  statement  about  the  behavior  of  a 
terminating  program.  A  program  is  said  to  satisfy  such  an  assertion  if  it  is  satisfied  by 
every  terminating  execution  of  the  program.  Therefore,  a  partial  correctness  assertion 
says  nothing  about  program  termination,  but  describes  what  will  be  true  if  and  when 
the  program  halts.  Hoare  describes  in  [Hoa69]  a  method  for  proving  that  sequential 
programs  satisfy  partial  correctness  assertions.  His  method  makes  use  of  the  observer 
tion,  first  noted  by  Floyd  in  [Flo67],  that  partial  correctness  assertions  satisfied  by  a 
program  S  can  be  expressed  in  terms  of  predicates  P  and  Q  describing  the  program 
state  before  and  after  the  execution  of  S.  More  formally,  if  P  and  Q  are  assertions 
about  program  variables  and  5  is  a  program  statement,  P{S}Q  denotes  the  assertion 
that  if  P  is  true  before  the  execution  of  S  begins,  then  Q  will  be  true  if  and  when  S 
terminates.  Given  a  few  simple  axioms,  Hoare  shows  how  to  derive  partial  correctness 
assertions  P{S}Q  for  arbitrary  programs  5.  In  the  first  step  of  the  derivation,  each 
statement  Si  of  S  is  annotated  with  assertions  Pi  and  Q,.  In  the  second  step,  each 
assertion  P«{Si}Q<  is  proven  using  axioms  describing  the  various  programming  lan¬ 
guage  constructs.  Finally,  general  rules  of  inference  (independent  of  any  programming 
language)  are  used  to  combine  these  assertions  into  a  proof  of  P{S}Q. 

Hoare ’s  method  has  proven  to  be  a  very  effective  method  of  verifying  sequential 
programs.  Most  interestingly,  it  is  possible  to  write  hierarchical  correctness  proofs. 
Each  program  module  5  can  be  specified  by  a  partial  correctness  assertion  P{S}Q. 
Having  proven  each  assertion  P{5}(?,  these  assertions  can  be  used  in  the  proof  of 
the  larger  program  without  reference  to  the  implementation  of  S.  Furthermore,  since 
reasoning  begins  with  a  collection  of  partial  correctness  assertions  characterising  pro¬ 
gram  behavior  and  proceeds  via  rules  of  inference,  this  process  can  be  automated  if 
programmers  are  willing  to  supply  certain  intermediate  assertions.  Compilers  for  the 
language  Euclid,  for  example,  attempt  to  construct  as  much  of  the  proof  as  possible 
(see  [LGH*78]).  Apt  has  written  a  comprehensive  survey  of  Hoare  logics  in  [Apt8l] 
and  [Apt84]. 

In  [OG76],  Owicki  and  Gries  extend  Hoare ’s  method  to  distributed  and  parallel  pro¬ 
grams.  Here,  too,  each  statement  Si  of  each  process  5  is  annotated  with  assertions  P, 
and  Qi,  and  partial  correctness  assertions  P{S}Q3  are  proven  for  each  process  5  in 
isolation  using  a  sequential  programming  logic  similar  to  Hoare's.  Unlike  sequential  al¬ 
gorithms,  however,  it  is  possible  for  one  process  action  to  affect  the  state  of  another.  In 
order  to  prove  partial  correctness  of  an  entire  system  of  process,  it  is  necessary  to  prove 
that  no  process  can  invalidate  assertions  appearing  in  the  sequential  proof  of  another 
process’s  partial  correctness.  Owicki  and  Gries  refer  to  this  condition  as  noninterfer¬ 
ence.  For  example,  if  P{S}Q  appears  in  the  proof  of  one  process  and  the  assertion  R 
labels  one  statement  appearing  in  another  process,  noninterference  requires  that  the 
assertion  (P  A  R){S}(Q  A  R)  hold;  that  is,  the  execution  of  S  does  not  invalidate  R. 

5 Owicki  »nd  Griea  Actually  um  the  notation  {P}S{Q}. 


This  method  of  Owicki  and  Gries  has  been  found  to  be  quite  successful,  just  as  Hoare’s 
method  has  been  found  to  be  successful  for  sequential  programs.  Gries  has  constructed 
a  nice  proof  of  Dijkstra’s  on-the-fly  garbage  collector  in  [Gri77],  an  algorithm  with  such 
fine  interleaving  that  the  only  atomic  action  required  is  memory  reference.  Levin  and 
Gries  show  in  [LG81]  how  the  method  of  Owicki  and  Gries  can  be  used  to  verify  CSP 
processes.  Furthermore,  Schlichting  and  Schneider  show  in  [SS84]  how  message  passing 
primitives  can  be  incorporated  into  this  framework. 

As  with  sequential  programs,  the  partial  correctness  of  systems  may  be  specified 
with  partial  correctness  assertions  of  the  form  P{S)Q.  Due  to  the  possibility  of  process 
interference,  however,  it  is  not  possible  to  specify  the  partial  correctness  of  individual 
processes  in  terms  of  such  assertions.  The  specification  of  a  process  must  also  describe 
its  environment  if  such  assertions  are  to  be  used.  Without  a  description  of  its  en¬ 
vironment,  it  is  impossible  to  prove  that  a  process  satisfies  most  partial  correctness 
assertions.  Furthermore,  modification  of  a  single  process  requires  redoing  a  major  por¬ 
tion  of  a  system’s  proof  of  correctness  since  it  must  be  shown  that  this  modification 
does  not  violate  partial  correctness  assertions  appearing  in  the  correctness  proofs  of 
other  processes.  Thus,  both  specifications  and  correctness  proofs  using  partial  correct¬ 
ness  assertions  of  the  form  P{S}Q  lack  an  important  modularity.  We  consider  this 
lack  of  modularity  to  be  a  major  problem  in  protocol  verification. 

Lamport  attempts  to  resolve  this  lack  of  modularity  in  [Lam80].  Here  Lamport 
redefines  the  assertion  P{S}Q  to  mean  that  if  execution  is  begun  anywhere  inside  S 
with  P  true,  then  executing  S  will  leave  P  true  while  control  is  inside  5,  and  will 
make  Q  true  if  and  when  5  terminates.  Such  a  definition  is  possible  for  Lamport  since 
he  allows  the  predicates  P  and  Q  to  refer  to  program  locations,  whereas  Owicki  and 
Gries  restricted  P  and  Q  to  program  variables.  The  advantage  of  Lamport’s  scheme 
is  that  partial  correctness  assertions  for  an  entire  system  can  be  verified  given  partial 
correctness  assertions  specifying  each  system  component.  After  system  correctness  has 
been  proven  from  component  specifications,  any  implementation  of  the  components 
satisfying  their  specifications  can  be  used  in  the  system’s  implementation.  Lamport’s 
method,  however,  is  not  without  its  difficulties.  For  example,  suppose  that  S  is  a 
system  component  making  heavy  use  of  shared  variables.  It  seems  difficult  to  construct 
assertions  P  that  are  invariant  throughout  the  execution  of  S  without  knowing  how  5 
uses  these  shared  variables. 

In  our  method,  the  problem  of  modular  specification  disappears  since  an  environ¬ 
ment  is  implicitly  specified  by  the  fact  that  input  actions  are  continuously  enabled.  (In 
other  words,  anything  can  happen  in  the  environment  of  a  process.)  As  a  result,  if 
a  partial  correctness  assertion  can  be  proven  about  process  behavior,  the  partial  cor¬ 
rectness  assertion  holds  regardless  of  the  process’s  actual  environment.  Thus  in  our 
method  it  is  no  longer  necessary  to  prove  noninterference  after  proving  the  correctness 
of  individual  processes.  Furthermore,  it  is  no  longer  necessary  to  redo  any  part  of  a 
correctness  proof  when  a  process  is  modified,  other  than  the  correctness  of  the  mod- 
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ified  process  itself.  (A  similar  consequence  of  such  input  requirements  can  be  found 
in  [MCS82],  [Sta84],  and  [LM86].)  Also,  notice  that  Hoare-style  specifications  do  not 
make  clear  the  interface  between  a  system  component  and  its  environment.  As  pre¬ 
viously  mentioned,  this  interface  is  crucial  to  the  definition  of  fair  computation.  In 
contrast,  our  model  clearly  defines  this  interface  as  the  set  of  actions  the  process  can 
perform,  together  with  information  about  which  actions  denote  input  and  output  of 
the  process. 

We  note  that  due  to  the  generality  of  automaton  transitions,  partial  correctness 
assertions  describing  automaton  transitions  similar  to  those  of  Hoare  describing  com¬ 
mon  programming  language  constructs  may  not  always  be  easy  to  find.  However,  if 
transitions  are  described  in  terms  of  preconditions  that  must  be  satisfied  before  an  ac¬ 
tion  can  be  performed,  and  the  effect  of  an  action  on  an  automaton  state,  then  partial 
correctness  assertions  can  be  constructed  for  each  action.  Furthermore,  the  general, 
language-independent  rules  of  inference  used  in  Hoare-like  systems  are  clearly  valid  in 
our  model  of  computation.  Thus,  while  we  do  not  make  use  of  such  arguments  in  our 
work,  it  is  possible  to  construct  Hoare-like  proofs  of  partial  correctness  assertions  in 
our  model. 

Notice  that  partial  correctness  assertions  describe  safety  properties,  and  not  liveness 
properties.  Since  there  is  no  notion  of  system  computation  in  these  Hoare  logics, 
there  is  no  notion  of  eventuality.  We  note  that  safety  properties  can  often  be  used  to 
prove  liveness  properties.  For  example,  Owicki  and  Gries  show  in  [OG76]  how  well- 
foundedness  arguments  can  be  incorporated  into  Hoare  logics  to  prove  termination  of 
programs.  Alpern  and  Schneider  go  farther  in  [AS85]  and  show  that  the  verification 
of  both  liveness  and  safety  properties  can  be  reduced  to  proving  what  are  essentially 
partial  correctness  assertions.  However,  the  specification  of  a  liveness  condition  in 
terms  of  partial  correctness  assertions  is  often  an  unintuitive  formulation. 

A  more  natural  expression  of  such  properties  is  possible  with  temporal  logic.  Tem¬ 
poral  logic  was  introduced  by  Pnueli  in  [Pnu77]  as  an  adaptation  of  classical  modal 
logic  suitable  for  reasoning  about  concurrent  programs.  The  two  paper  series  [MP81b] 
and  [MP81a]  by  Manna  and  Pnueli  is  a  thorough  introduction  to  the  expression  of  prop¬ 
erties  of  concurrent  programs,  and  the  verification  of  these  properties,  using  temporal 
logic.  Here  the  meaning  of  a  system  computation  is  a  sequence  of  system  states.  The 
fundamental  temporal  operators  are  the  unary  operator  □  and  its  dual  O.  Loosely 
speaking,  a  computation  satisfies  the  expression  OP,  pronounced  “henceforth  P,"  if  P 
is  true  throughout  the  computation;  and  a  computation  satisfies  the  expression  OP, 
pronounced  “eventually  P,”  if  there  is  a  point  during  the  computation  at  which  P  is 
true.  Many  interesting  properties  of  computation  may  be  specified  with  these  simple 
operators.  For  instance,  the  expression  D(P  D  OQ)  states  that  the  property  P  causes 
the  property  Q  to  hold;  the  expression  OOP  states  that  the  property  P  holds  infinitely 
often. 

Temporal  logic  is  a  useful  abstraction  with  which  to  specify  and  reason  about  pro- 


gram  behavior.  Since  the  meaning  of  a  computation  is  a  sequence  of  states,  temporal 
logic  is  able  to  express  liveness  properties  as  well  as  safety  properties,  and  these  ex¬ 
pressions  are  typically  quite  concise.  Since  reasoning  in  temporal  logic  begins  with  a 
collection  of  axioms  characterizing  program  behavior,  and  proceeds  via  general  rules  of 
inference,  reasoning  in  temporal  logic  has  potential  for  automation.  Furthermore,  while 
Hoare  logics  make  use  of  inference  rules  that  are  independent  of  any  programming  lan¬ 
guage,  most  of  the  work  in  a  Hoare-style  proof  deals  with  language-specific  semantics. 
In  contrast,  reasoning  in  temporal  logic  is  valid  for  all  programs.  The  difficulty,  of 
course,  is  in  abstracting  from  an  implementation  to  a  temporal  logic  characterisation 
of  its  behavior,  and  this  problem  is  often  swept  under  the  rug. 

A  great  deal  of  work  in  temporal  logic  concerns  reasoning  about  system  correctness 
after  system  components  have  been  specified  in  terms  of  temporal  logic  (see,  for  ex¬ 
ample,  [HO80],  [SM81],  [OL82],  [Lam83],  [Sta84]  and  [NG085]).  The  most  dramatic 
distinction  between  these  works  is  the  way  in  which  temporal  logic  is  used  to  describe 
system  behavior.  Schwartz  and  Melliar-Smith  give  purely  temporal  specifications  of 
programs  in  [SM81].  In  these  specifications,  even  the  notion  of  a  process  state  has  been 
replaced  by  temporal  specifications.  Consequently,  the  resulting  specifications  are  quite 
complex,  involving  nested  “until"  operators  in  addition  to  the  temporal  operators  de¬ 
scribed  above.  These  specifications  are  often  difficult  to  understand,  and  difficult  to 
reason  about.  On  the  other  hand,  Hailpern  and  Owicki  make  great  use  of  the  notion  of 
program  state  in  [HO80].  They  add  history  variables  to  the  program  state  that  describe 
the  history  of  events  over  communication  links,  and  reason  about  the  values  assumed 
by  these  variables.  History  variables  are  a  convenient  descriptive  tool  found  in  many 
proof  styles,  and  the  specifications  produced  by  Hailpern  and  Owicki  are  generally  easy 
to  understand.  The  history  variables,  however,  do  not  affect  program  behavior,  and  in 
proofs  reasoning  about  history  variables  the  history  variables  themselves  seem  extrane¬ 
ous.  Between  the  extremes  of  [SM81]  and  [H080]  is  the  work  of  Lamport  in  [Lam83j. 
Here  the  process  state  modeled  consists  only  of  program  variables,  and  temporal  logic 
assertions  describe  the  sequence  of  values  these  variable  assume.  Although  an  automa¬ 
ton  state  can  be  seen  as  a  natural  extension  of  history  variables,  our  proofs  tend  to 
have  a  flavor  similar  to  those  of  Lamport’s  in  [Lam83]. 

While  a  great  deal  of  work  has  studied  the  problem  of  reasoning  about  systems  after 
system  components  have  been  specified  in  terms  of  temporal  logic,  less  has  been  devoted 
to  proving  that  an  implementation  actually  meets  its  temporal  logic  specification.  One 
attempt  is  that  of  Owicki  and  Lamport  in  [OL82],  improving  on  the  work  of  Lamport 
in  [Lam77j.  Since  safety  properties  can  be  proven  using  methods  of  Owicki  and  Gries, 
of  particular  interest  is  the  style  of  proving  liveness  properties  Owicki  and  Lamport 
describe.  Owicki  and  Lamport  construct  diagrams  called  proof  lattices  that  outline  the 
structure  of  a  proof  of  a  liveness  property.  Informally,  a  proof  lattice  is  an  acyclic 
directed  graph  with  a  single  entry  node  having  no  incoming  edges,  and  a  single  exit 
node  having  no  outgoing  edges.  Nodes  of  the  graph  are  labeled  with  assertions.  A 
node  labeled  A  with  outgoing  edges  to  nodes  labeled  Aj, . . . ,  An  denotes  the  assertion 
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that  if  A  hold*,  then  one  of  the  assertions  Ai, . . . ,  A„  must  eventually  hold;  that  is 
A  D  0(Ai  V ...  V  An).  Suppose  each  such  assertion  can  be  proven  for  a  program.  If  the 
entry  node  is  labeled  with  A  and  the  exit  with  B,  then  the  proof  lattice  amounts  to  a 
proof  of  the  livenees  property  A  D  OB  for  the  program.  Manna  and  Pnueli  extend  the 
use  of  proof  lattices  in  (MP84).  In  this  work,  however,  an  automata-theoretic  model 
of  computation  is  explicitly  defined,  and  proof  rules  are  given  for  proving  that  each 
assertion  denoted  by  edges  of  the  proof  lattice  is  satisfied  by  the  system  modeled  by 
an  automaton.  We  find  this  work  a  very  satisfying  example  of  how  an  automata- 
theoretic  model  of  computation  and  temporal  logic  can  be  used  together.  Given  an 
automata-theoretic  description  of  system  implementation,  temporal  logic  provides  a 
useful  abstraction  for  reasoning  about  system  behavior.  While  we  have  not  fixed  on 
one  particular  specification  language,  we  feel  that  temporal  logic  and  our  automata- 
theoretic  model  of  computation  can  work  well  together.  In  particular,  through  the 
use  of  automata  we  are  able  to  incorporate  temporal  logic  into  hierarchical  correctness 
proofs. 

The  use  of  abstraction  is  an  important  aspect  of  our  style  of  algorithm  verification. 
Most  work  in  the  literature  claiming  to  produce  proofs  with  a  hierarchical  structure 
actually  allow  system  components  to  be  verified  independently,  and  then  combined 
to  verify  the  correctness  of  the  system.  This  notion  of  hierarchical  verification  is  a 
restricted  version  of  the  notion  we  use  in  this  work.  Here  we  actually  construct  models 
of  the  entire  system  at  conceptually  different  levels  of  abstraction,  rather  than  merely 
combining  local  process  states  into  global  system  states. 

Our  work  most  closely  resembles  that  of  Lamport  in  [Lam83].  Here  Lamport  spec¬ 
ifies  a  program  with  a  collection  of  state  functions  mapping  program  states  into  sets  of 
values,  a  collection  of  initial  conditions  essentially  defining  the  set  of  states  in  which 
the  system  may  begin  computation,  and  a  collection  of  properties  describing  safety  and 
liveness  conditions.  We  note  that  the  values  to  which  states  are  mapped  by  state  func¬ 
tions  can  be  thought  of  as  state  variables  describing  relevant  aspects  of  the  system  to  be 
implemented.  Furthermore,  the  properties  included  in  the  system  specification  define 
allowed  and  required  changes  in  the  values  these  variables  assume.  If  these  variables 
are  collected  into  states,  then  the  variables  together  with  the  properties  essentially  de¬ 
fine  an  automaton  together  with  a  collection  of  eventuality  conditions  restricting  the 
computations  of  the  automaton.  If  the  program  implementing  the  specified  system  is 
considered  to  be  an  automaton,  as  is  implicitly  the  case  in  Lamport’s  work,  then  the 
state  functions  can  be  thought  of  as  mappings  from  an  automaton  describing  the  sys¬ 
tem  at  one  level  of  abstraction  to  an  automaton  describing  the  system  at  a  higher  level 
of  abstraction.  This  is  the  technique  used  in  our  work.  Our  work  is  an  improvement 
on  that  of  Lamport’s  in  the  sense  that  we  carry  his  style  of  specifications  to  its  natural 
conclusion,  making  the  automata-theoretic  flavor  of  his  work  explicit.  Furthermore, 
we  make  explicit  his  underlying  assumption  that  what  is  important  about  a  process 
is  the  externally  observable  behavior  of  the  process.  His  work  seems  to  imply  that 
the  variables  and  state  functions  must  be  describing  some  aspect  of  the  system  that 
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must  appear  in  the  implementation.  We  feel,  however,  that  they  are  to  be  considered 
merely  descriptive  tools,  and  that  the  notion  of  subset  containment  used  as  the  notion 
of  correctness  in  this  work  is  the  notion  of  correctness  actually  underlying  Lamport’s 
work. 

Other  work  similar  to  ours  is  that  of  Stark  in  [Sta84j.  Many  of  the  aims  and  ideas 
underlying  his  work  are  the  same  as  ours,  but  his  model  is  much  more  general  than 
ours.  We  find  our  model  to  be  simpler  and  easier  to  use  than  Stark’s,  and  expressive 
enough  to  describe  most  systems  of  interest.  Work  on  hierarchical  verification  also 
includes  that  of  Lam  and  Shankar  in  [LS84aJ;  Harel  in  [Har87];  and  Lamport,  Lynch, 
and  Welch  in  [LLW87],  Each  of  these  techniques  analyses  an  algorithm  by  abstracting 
away  certain  portions  of  the  algorithm  (rather  than  mapping  to  an  entirely  different 
level  of  conceptual  abstraction  as  we  do  here)  and  studying  the  remaining  '‘image’’  of 
the  original  algorithm.  To  Lam  and  Shankar,  the  advantage  of  this  method  seems  to 
be  that  it  allows  highly  interdependent  modules  of  a  sy&  .em  to  be  studied  in  isolation. 
Lamport,  Lynch,  and  Welch  seem  to  be  taking  this  notion  of  ‘projection*  one  step 
further.  They  show  how  projections  onto  different  modules  can  be  combined  into  a 
proof  of  the  entire  system,  giving  the  proof  a  lattice-like  structure.  While  still  work 
in  progress,  their  work  seems  to  be  shedding  new  light  on  the  intellectual  organisation 
of  protocol  verification.  The  progress  being  made  in  their  research  can  certainly  be 
incorporated  into  ours. 

The  remainder  of  this  thesis  consists  of  two  parts.  First,  in  Chapter  2,  we  formally 
define  our  model  of  computation  and  develop  the  machinery  needed  to  use  our  model 
in  the  construction  of  hierarchical  correctness  proofs.  Then,  in  Chapter  3,  we  illustrate 
the  use  of  our  model  by  proving  the  correctness  of  Schonh  age’s  distributed  resource 
arbiter.  Finally,  in  Chapter  4,  we  end  with  some  concluding  remarks,  including  some 
ideas  for  future  work. 
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Chapter  2 


The  Input-Output  Automaton 
Model 


In  thia  chapter  we  define  the  input-output  automaton  model.  We  begin  with  a  formal 
definition  of  an  input-output  automaton,  and  define  operation*  that  may  be  performed 
on  automata,  including  the  composition  of  automata.  We  then  show  how  fairness 
can  be  modeled  with  automata.  Finally,  we  develop  the  machinery  necessary  to  use 
automata  in  the  construction  of  modular,  hierarchical  correctness  proofs  for  distributed 
algorithms. 


2.1  Input-Output  Automata 

Having  informally  described  our  model  in  the  introduction,  we  now  formally  define 
an  input-output  automaton.  Since  the  actions  of  an  automaton  define  the  interface 
between  an  automaton  and  its  environment,  it  is  convenient  to  be  able  to  refer  to 
this  interface  explicitly.  Given  three  disjoint  sets  in,  out,  and  int  of  input,  output,  and 
internal  actions,  respectively,  we  refer  to  the  triple  (in,  out,  int)  as  an  notion  signature  S. 
We  denote  the  seta  in,  out,  and  int  by  in(5),  out(S),  and  tnt(5),  respectively;  and  we 
denote  the  entire  set  of  actions  in  U  out  U  int  by  acts(S).  Since  int  is  the  set  of 
internal  actions,  it  is  natural  to  refer  to  in  U  out  as  the  set  of  external  actions,  denoted 
by  ext(S).  Finally,  we  denote  the  set  int  U  out  of  locally-controlled  actions  by  loeal(S). 

An  input-output  automaton  (or  automaton )  A  consists  of  five  components: 

1.  a  set  states(A)  of  states, 

2.  a  set  start(A)  C  states(A)  of  start  states, 

3.  an  action  signature  ft? (A), 


V 

V 


4.  a  transition  relation  step* (A)  C  states(A)  x  o«t«(#tf(A))  x  states  (A),  with  the 
property  that  for  every  state  a  and  input  action  x  there  is  a  transition  (a,*, a') 
in  steps(A),  and 


5.  an  equivalence  relation  part(A)  on  local  (rig  (A)). 


V 


Notice  that  the  transition  relation  steps  (A)  has  the  property  that  input  actions  are 
continuously  enabled,  as  mentioned  in  the  introduction.  Notice,  also,  that  the  equiva¬ 


lence  relation  port  (A)  is  the  partition  of  the  locally-controlled  actions  alluded  to  in  the 
introduction.  This  partition  will  be  used  when  we  define  the  notion  of  fair  computation 
in  Section  2.2. 

We  refer  to  an  element  (a,  x,  a1)  of  steps(A)  as  a  x-step  from  a  to  o'.  It  will  occasion¬ 
ally  be  convenient  to  denote  the  step  (a,  x,  a')  by  a  a',  and  to  denote  the  sequence  of 
steps  ao^S|...^a,byao  a*.  The  step  (a,*, a')  is  called  an  input  step  if  w  is 
an  input  action,  and  output  steps,  internal  steps ,  external  steps ,  and  locally-controlled 
steps  are  similarly  defined.  If  (o,  x,  a')  is  a  step  of  A,  then  x  is  said  to  be  enabled 
from  a.  Since  every  input  action  is  enabled  from  every  state,  automata  are  said  to  be 
input- enabled. 

An  execution  fragment  of  A  is  a  finite  sequence  aos^ai . . .  or  infinite  sequence 
aoV1a1X)ai ...  of  alternating  states  and  actions  such  that  is  a  step  of  A 

for  every  i.  An  execution  fragment  beginning  with  a  start  state  is  called  an  execution. 
We  denote  the  set  of  executions  of  A  by  exees(A).  A  state  is  said  to  be  reachable  if  it  is 
the  final  state  of  a  finite  execution.  The  schedule  of  an  execution  x  is  the  subeequence 
of  actions  appearing  in  x,  denoted  by  sched(x).  We  denote  the  set  of  schedules  of  A  by 
scheds(A). 

We  will  soon  consider  certain  su beets  of  an  automaton’s  executions  or  schedules 
(such  as  the  set  of  fair  computations)  to  be  of  particular  interest.  Since  we  will  com¬ 
pose  automata,  it  will  be  necessary  to  have  ways  of  composing  sets  of  executions  or 
schedules  as  well.  If  these  compositions  are  to  be  meaningfully  related,  however,  cer¬ 
tain  information  about  the  structure  of  the  original  automata  must  be  retained.  In 
particular,  it  is  important  to  retain  information  about  the  action  signatures  of  these 
automata.  We  are  therefore  led  to  define  the  notions  of  execution  modules  and  sched¬ 
ule  modules,  essentially  sets  of  executions  or  schedules,  respectively,  together  with  an 
action  signature. 

An  execution  module  E  consists  of  a  set  states(E)  of  states,  an  action  signature 
sig(E),  and  a  set  execs(E)  of  executions.  Each  execution  of  E  is  an  alternating  sequence 
of  states  and  actions  of  E  beginning  with  a  state,  and  ending  with  a  state  if  the 
sequence  is  finite.  Each  execution  x  has  an  associated  schedule  sched(x)  that  consists 
of  the  subsequence  of  actions  appearing  in  r.  We  denote  the  set  of  schedules  of  E  by 


echtds  (E).  An  execution  module  E  is  said  to  be  an  execution  module  of  an  automaton  A 
if  E  and  A  have  the  same  states,  the  same  action  signature,  and  the  executions  of  E 
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Are  contained  in  the  executions  of  A.  Notice  that  An  execution  module  E  is  always 
An  execution  module  of  some  AutomAton.  In  p Articular,  E  is  An  execution  module 
of  the  AutomAton  having  the  stAtes  And  Action  signAture  of  E,  And  the  transition 
relation  etates(E)  x  acts  (rig  (E))  x  states  (E).  We  denote  the  execution  module  of 
the  automaton  A  having  execs(A)  as  its  set  of  executions  by  Execs  (A).  (We  follow 
the  convention  of  denoting  sets  with  lower  case  names  and  modules  with  capitalised 
names.) 

A  schedule  module  S  consists  of  an  action  signature  sig(S)  together  with  a  set 
scheds(S)  of  schedules.  Each  schedule  of  5  is  a  finite  or  infinite  sequence  of  the  actions 
of  5.  Given  an  execution  module  E,  there  is  a  natural  schedule  module  associated 
with  E  consisting  of  the  action  signature  and  schedules  of  E.  We  denote  this  schedule 
module  by  Scheds(E),  and  write  Seheds(A)  as  shorthand  for  Scheds(Ezecs(A)). 

We  refer  collectively  to  automata,  execution  modules,  and  schedule  modules  as 
objects ,  the  type  of  an  object  determining  whether  it  is  an  automaton,  execution  module, 
or  schedule  module.  For  notational  convenience,  given  an  object  O  we  often  omit 
reference  to  its  action  signature  and  write,  for  example,  in(0)  for  in(rig(0)). 

Since  it  is  typically  the  case  that  more  than  one  automaton  can  model  the  same 
process,  some  notion  of  equivalence  is  needed.  Intuitively,  the  external  observer  of  a 
process  (a  user  of  the  process,  for  instance)  can  detect  only  the  sequence  of  actions 
performed  by  the  process.  In  fact,  the  only  actions  detectable  by  such  an  observer 
are  the  external  actions  of  the  process.  We  are  therefore  led  to  define  a  notion  of 
equivalence  determined  by  the  externally  visible  sequences  of  actions  produced  by  an 
object.  Since  we  will  consider  in  Section  2.2.2  a  second  notion  of  equivalence  based  on 
the  fair  behavior  of  an  object,  we  refer  the  the  current  notion  of  equivalence  as  unfair 
equivalence. 

We  begin  by  defining  an  operation  that  essentially  extracts  the  externally  visible 
behavior  of  an  object.  An  external  action  signature  is  an  action  signature  consisting 
entirely  of  external  actions;  that  is,  having  no  internal  actions.  The  external  action  sig¬ 
nature  of  an  object  O  is  the  action  signature  obtained  by  removing  the  internal  actions 
from  the  action  signature  of  O.  An  external  schedule  module  is  a  schedule  module  with 
an  external  action  signature.  Given  a  sequence  y  of  actions  and  a  set  II  of  actions,  we 
denote  by  y|II  the  subsequence  of  y  consisting  of  actions  from  II.  The  external  schedule 
module  of  an  object  O,  denoted  by  External  (O),  is  the  external  schedule  module  with 
the  external  action  signature  of  0  and  the  schedules  {y\ext(0)  :  y  €  schods(O)}  ob¬ 
tained  by  removing  the  internal  actions  from  the  schedules  of  O.  We  define  the  unfair 
behavior  of  O,  denoted  by  Ubeh(0 ),  to  be  the  external  schedule  module  External (O). 

Two  objects  O  and  P  of  the  same  type  are  said  to  be  unfairly  equivalent ,  denoted  by 
O  ""£“r  Py  if  Ubeh(0)  =  Ubeh(P).  This  equivalence  is  clearly  an  equivalence  relation, 
and  we  will  see  that  it  is  also  a  congruence  with  respect  to  the  operations  we  now  define 
on  objects. 
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2.1.1  Composition 

To  build  models  of  complex  systems,  we  compose  models  of  simpler  system  components. 
In  this  section  we  show  how  to  compose  objects  to  construct  such  models. 

Composition  of  Automats 

Informally,  the  composition  of  a  collection  of  automata  is  their  Cartesian  product,  with 
the  added  requirement  that  automata  synchronise  the  performance  of  shared  actions. 
That  is,  each  automaton  is  allowed  to  take  steps  independently,  with  the  restriction 
that  if  one  automaton  takes  a  x-step,  then  all  automata  sharing  x  as  an  action  must 
also  take  a  ir-step.  This  synchronization  models  communication  between  system  com¬ 
ponents:  If  *  is  an  output  action  of  A  and  an  input  action  of  B,  then  the  simultaneous 
performance  of  ir  models  communication  from  A  to  B.  Since  synchronisation  is  meant 
only  to  model  communication,  however,  two  automata  sharing  n  as  an  output  action 
should  not  be  required  to  perform  n  simultaneously.  We  note  that  two  processors 
cannot  be  expected  to  perform  an  output  action  simultaneously  in  an  asynchronous 
system.  Rather  than  complicate  the  notion  of  composition,  we  require  instead  that  the 
output  actions  of  composed  automata  be  disjoint.  Since  internal  actions  are  meant  to 
model  externally  undetectable  actions,  we  are  faced  with  the  need  for  a  similar  restric¬ 
tion  for  internal  actions.  We  require  that  the  internal  actions  of  each  automaton  in  a 
composition  be  disjoint  from  the  actions  of  the  remaining  automata. 

Having  restricted  the  composition  of  automata  to  those  with  suitably  compatible 
action  signatures,  determining  the  type  of  an  action  in  a  composition  is  fairly  simple: 
Output  actions  of  the  component  automata  become  output  actions  of  the  composition, 
internal  actions  of  component  automata  become  internal  actions  of  the  composition, 
and  all  remaining  (input)  actions  of  the  component  automata  become  input  actions  of 
the  composition.  Notice  that  the  composition  of  automata  does  not  hide  communication 
between  component  automata.  To  hide  such  communication  will  require  the  use  of  a 
hiding  operation  defined  later  in  Section  2.1.2. 

Finally,  recall  that  associated  with  every  automaton  (in  particular,  with  a  compo¬ 
sition  of  automata)  is  a  partition  of  its  locally-controlled  actions.  Our  intuitive  under¬ 
standing  of  this  partition  is  that  each  class  represents  the  locally-controlled  actions  of 
one  system  component.  A  natural  partition  of  a  composition’s  locally-controlled  actions 
is  to  place  the  locally-controlled  actions  of  each  component  automaton  in  a  separate 
class.  Since  the  restrictions  we  impose  on  the  composition  of  automata  ensure  that 
the  locally-controlled  actions  of  the  component  automata  are  disjoint,  this  is  indeed 
a  partition.  However,  each  component  automaton  may  model  many  system  compo¬ 
nents.  We  therefore  partition  a  composition's  locally-controlled  actions  by  taking  each 
class  of  each  component  automaton  as  a  separate  class  of  the  composition’s  partition. 
That  is,  the  partition  of  a  composition's  locally-controlled  actions  is  the  union  of  its 
components’  partitions. 
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We  ere  now  in  a  poeition  to  formally  define  the  compoeition  of  automata.  We  begin 
by  defining  a  compoeition  of  action  signatures.  Previous  discussion  suggests  that  the 
action  signatures  {5,  :  i  €  1}  be  called  compatible  if  for  all  ij  el  we  have 

1.  out(Si)  n  out(Sj)  =  0,  and 

2.  int(Si)  n  acts(Sj)  =  0. 

In  general,  we  say  that  the  objects  {O,-  :  t  €  /}  are  compatible  if  their  action  signer 
tures  are  compatible.  The  composition  S  =  fLe/  $  of  compatible  action  signatures 
{5<  :  *  €  /}  is  defined  to  be  the  action  signature  with 

1.  »n(S)  as  U  in  (Si)  —  U  outfS,), 

»€/  •€/ 

2.  out(S)  =  U  out(Si),  and 

•€/ 

3.  int(S)  =  U  t'ni(Si). 

*€/ 

Notice  that  this  composition  is  commutative  and  associative. 

The  composition  A  =  n,€/  At  of  compatible  automata  {A*  :  »  €  /}  is  defined  to  be 
the  automaton  with 


1.  states  (A)  =  fl  states(Ai), 

•€/ 

2.  start  [A)  =  I]  start(Ai), 

•€/ 

3.  sig(A)  m  n  *ig{Ai), 

•€/ 

4.  part  [A)  =  |J  port  (A*),  and 

»€/ 

5.  steps(A)  equal  to  the  set  of  triples  ({ai}  ,  v,  {o'})  such  that  for  all  t  €  / 

(a)  if  w  e  acts{Ai)  then  (aj,*,a{)  e  steps  (Ai),  and 

(b)  if  w  &  acts  (A,)  then  Oi  =  o{. 


Notice  that  since  the  automata  A,  are  input-enabled,  so  is  their  composition,  and  hence 
their  composition  is  an  automaton.  When  /  is  a  finite  set  {1, ...  ,n},  we  will  frequently 
denote  the  composition  n<  A<  by  Ai  • . . .  ■  A„. 

As  a  simple  example  of  automaton  composition,  consider  the  two  automata  A  and  B 
shown  at  the  top  of  Figure  2.1,  and  their  composition  A  •  B  shown  at  the  bottom  of  the 
same  figure.  (A  caret  points  to  the  single  initial  state  of  each  automaton.)  The  action  a 
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is  an  output  action  of  A  and  an  input  action  of  B,  and  the  action  0  is  an  output  action 
of  B  and  and  input  action  of  A.  Notice  that  since  each  waits  for  the  other  to  take  an 
output  step  before  taking  an  output  step  itself,  the  automata  A  and  B  alternate  output 
steps  in  executions  of  the  composition  A  •  B.  Notice,  furthermore,  that  since  a  and  0 
are  output  actions  of  A  and  B,  respectively,  all  actions  of  the  composition  A  •  B  are 
output  actions.  Finally,  notice  that  the  partition  of  the  composition’s  locally-controlled 
actions  (in  this  case,  the  output  actions)  places  a  and  0  in  separate  equivalence  classes. 

The  composition  of  automata  has  two  simple  properties.  First,  an  execution  of  a 
composition  A  =  IL  A  always  induces  executions  in  the  component  automata  A,.  If 
a  -  {a,}  is  a  state  of  A ,  let  a|A«-  =  a*.  If  z  =  ao*i&\ ...  is  an  execution  of  A ,  let  x\Ai  be 
the  sequence  obtained  by  deleting  x,a,  when  x,  is  not  an  action  of  A,,  and  replacing 
the  remaining  a,  with  a,-| A*.  We  now  have  the  following: 

Lemma  1:  If  z  €  exees( fl  A,),  then  z|A*  6  exect(Ai)  for  all »  €  /. 

<€/ 

Proof:  Let  A  =  FI.  and  suppose  that  z  =  aoXidi  —  By  the  definition  of  an 
execution,  <*o  is  a  start  state  of  A,  and  every  triple  (a*_i ,xfc,ak)  is  a  step  of  A.  Two 
facts  follow  from  the  definition  of  the  composition  A.  First,  ao|A«  must  be  a  start  state 
of  Ai.  Second,  if  xk  is  an  action  of  A,  then  (o*-i|A*,  xk,  o*|A<)  is  a  step  of  A,.  If  x*  is 
not  an  action  of  Aj  then  a*_i!A,  =  a*|A,-.  Thus,  if  z|A,  =  •  •  •*  then  «o  ’•*  a  start 


state  of  At,  and  every  triple  (*y-i,0y,sy)  is  a  step  of  A,-.  Therefore,  x\Ai  is  an  execution 
of  Ai.  □ 

Conversely,  under  certain  conditions  an  execution  of  a  composition  is  induced  by 
executions  of  its  components.  Here  and  elsewhere,  we  denote  y\acta(0)  by  y\0  for 
arbitrary  objects  O. 

Lemma  2:  Let  {A,  :  t  €  /}  be  a  collection  of  compatible  automata.  Let  z<  be  an 
execution  of  Ai  for  every  *  €  I,  and  let  y  be  a  sequence  of  actions  from  the  Ai.  If 
y\Ai  =  teked(xi)  for  every  »  6  J,  then  there  is  an  execution  z  of  n.€/  A*  such  that 
y  =  ached(x),  and  z<  =  x\Ai  for  every  i  €  I. 

Proof:  Let  A  =  I"I.  A,.  Suppose  that  y  =  xixt . . ..  Since  y\At  =  ached  (ii),  we  can 
write  Xi  =  oJs-jjO^ir.jO* —  Let  »o  =  0.  Let  z  =  aoxiai...  where  o,  is  defined  as 
follows:  If  it  <  j  <  tjk+i,  then  ay | A,-  =  a*t.  That  is,  the  automaton  A*  remains  in 
state  a\  between  the  performance  of  actions  end  xy4+l ,  and  changes  state  to  a*+i 
upon  the  performance  of  x,4+1.  First,  we  claim  that  ao  is  a  start  state  of  A.  Since  for 
all  »  we  have  that  t0  =  0  implies  ao|A,-  =  Oq,  a  start  state  of  A,,  we  are  done.  Second, 
we  claim  that  (ay-i,xy,ay)  is  a  step  of  A  for  all  j.  Suppose  Xy  g  acts  (A,).  Then 
Xj  =  Xik  for  some  k.  It  follows  that  ay_x|A,-  =  a\_1  and  ay|A,-  =  a\  since  i*_j  <  j  =  i*. 
Thus,  (ay-xlA,,  ?ry,ay|A,)  is  a  step  of  Ai.  Conversely,  suppose  x,  £  acts  (A*).  Then 
>*  <  j  <  **+ 1,  and  it  follows  that  a,_i|A<  =  a'fc  =  o,|A<.  In  either  esse,  (a;_x,xy,ay) 
is  a  step  of  A  for  all  j.  It  follows  that  z  is  an  execution  of  A,  and  furthermore  that 
y  =  sched(x)  and  z|A,-  =  n  for  all  i.  □ 

The  following  corollary,  essentially  Lemma  4  from  [LM86],  ensures  that  composition 
preserves  the  notion  that  a  system  component  controls  the  performance  of  its  own 
locally-controlled  actions.  As  a  result,  when  reasoning  about  the  enabling  of  an  action  in 
a  composition,  it  is  enough  to  reason  about  the  enabling  of  the  action  at  one  component. 

Corollary  S:  Let  y  be  a  finite  schedule  of  a  composition  A  =  Let  x  be  a 

locally-controlled  action  of  A,-,  and  let  y1  =  yx.  If  ]/\Ai  is  a  schedule  of  A,-,  then  yf  is  a 
schedule  of  A. 

Proof:  Since  y  is  a  finite  schedule  of  A,  there  is  a  finite  execution  z  of  A  such  that 
y  =  sehed(x).  By  Lemma  1,  zjA;  is  an  execution  of  Ay  for  every  j  €  /.  Since  x  is  a 
locally-controlled  action  of  A, ,  if  x  is  an  action  of  Ay  (for  any  j  /  :),  then  x  is  an  input 
action  of  Ay.  Since  the  Ay  are  input-enabled,  and  since  y'jA,  is  a  schedule  of  A,,  for 
every  j  £  I  there  is  an  execution  Zy  of  Ay  such  that  j/|Ay  =  ached (zy).  By  Lemma  2, 
there  is  an  execution  x1  of  A  such  that  y  =  ached  (x1),  and  hence  y  is  an  execution  of  A. 

□ 
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Composition  of  Execution  Modules 

We  now  define  the  composition  of  execution  modules.  The  composition  E  =  ILe/ 
of  compatible  execution  modules  {Ei  :  i  €  /}  is  defined  as  follows.  The  states  of  E 
are  flig/  atatea(Ei),  and  the  action  signature  is  rLer  •*9(Ei).  Given  a  state  a  =  {a,}  of 
the  composition,  we  define  *|E,-  =  a,.  Given  a  sequence  x  =  *0*1*1 ...  of  states  and 
actions  of  E,  we  define  x|Ey  to  be  the  sequence  obtained  by  removing  iry*y  if  *j  is  not 
an  action  of  Ei,  and  replacing  the  remaining  ay  by  *y|E<.  The  executions  of  E  are  those 
sequences  *0*1*1 . . .  such  that  for  every  t  €  /  we  have  that  x|E,-  is  an  execution  of  E,, 
and  that  *y_i|Ey  =  ay | E,  whenever  *y  is  not  an  action  of  E,.  The  next  lemma  gives  an 
alternative  characterization  of  the  composition  of  execution  modules. 

Lemma  4:  Let  {Ei  :  i  €  /}  be  a  collection  of  compatible  execution  modules.  Sup¬ 
pose  Ei  is  an  execution  module  of  an  automaton  Ay  for  every  t  €  /.  Then  fLe/  E,  is 
the  execution  module  of  n,e/  A,  with  executions  x  such  that  x|Ay  is  an  execution  of  E, 
for  every  i  €  I. 

Proof:  Let  E  =  [L  Ei  and  A  =  n<  A,.  Since  E,  is  an  execution  module  of  A,,  it 
follows  that  Ei  and  A«  have  the  same  states  and  action  signature,  and  hence  so  do  E 
and  A.  We  need  only  check  that  the  executions  of  E  are  the  executions  x  of  A  such 
that  x| Ai  is  an  execution  of  Ei.  Suppose  x  is  an  execution  of  E.  The  execution  x  is 
a  sequence  *0*1*1 ...  of  states  and  actions  of  E  such  that  x|Ey  is  an  execution  of  E,, 
and  *,_i|E,  =  *y|E,  whenever  jry  is  not  an  action  of  Ey.  Since  Ey  is  an  execution 
module  of  Ai,  («y_i|Ay,  iry,*y|Ay)  is  a  step  of  Ai  whenever  is  an  action  of  Ai,  and 
*y _  1 1  Ai  =  * y  |  Ai  whenever  *7  is  not  an  action  of  A,.  It  follows  that  x  is  an  execution  of  A, 
and  furthermore  that  x|Ay  is  an  execution  of  E,  for  every  »  6  /.  Conversely,  suppose  x 
is  an  execution  of  A  such  that  x|A<  is  an  execution  of  E,  for  every  1  €  /.  Clearly,  x 
is  a  sequence  *0*1*1 ...  of  states  and  actions  of  E  such  that  x|E,  is  an  execution  of  Ei 
for  every  t  €  /.  Furthermore,  from  the  definition  of  the  composition  of  automata  we 
see  that  *y-i|E,  =  *y|E,  whenever  *y  is  not  an  action  of  Ey.  It  follows  that  x  is  an 
execution  of  E,  as  desired.  □ 

This  composition  is  defined  so  that  the  following  result  holds. 

Lemma  5:  For  all  compatible  automata  {Ay  :  *  €  /}, 

Execs  { n  Ai)  =  U  Execs(Ai). 

•€/  »€/ 

Proof:  Let  A  =  FI.  A,.  Furthermore,  let  EC  =  Exec* (Hi  A,)  and  CE  =  riy  Exec* (A,). 
Notice  that  EC  is  an  execution  module  of  A.  Furthermore,  since  Ezecs(Ai)  is  an 
execution  module  of  A,  for  every  »  6  I,  Lemma  4  implies  that  CE  is  also  an  execution 
module  of  A.  It  follows  that  EC  and  CE  have  the  same  states  and  action  signature. 
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We  need  only  show  that  they  have  the  same  executions.  By  Lemmas  1  and  4,  z  is  an 
execution  of  EC  iff  x  is  an  execution  of  A  such  that  x|A«  is  an  execution  of  A,  for  every 
»  €  /  iff  x  is  an  execution  of  CE.  Thus,  EC  and  CE  have  the  same  executions,  and 
hence  are  equal.  □ 


Composition  of  Schedule  Modules 

We  now  define  the  composition  of  schedule  modules.  The  composition  flie/  $  of  com¬ 
patible  schedule  modules  {5,-  :  t  £  /}  is  defined  to  be  the  schedule  module  with  action 
signature  [Le/  >*d(Si),  and  schedules  y  such  that  y| is  a  schedule  of  Si  for  every  i  €  I. 
This  composition  is  defined  so  that  the  following  result  holds. 

Lemma  6:  For  all  compatible  execution  modules  {£,  :  s  6  /}, 

Seheds([[  Ei)  =  HSeheds(Ei). 

»€/  •€/ 

Proof:  Let  SC  =  Seheds  (fl,  £.)  &nd  CS  —  f],  Scheda(E,).  Since  SC  and  CS  clearly 
have  the  same  action  signatures,  we  need  only  show  that  they  have  the  same  schedules. 
Suppose  Ei  is  an  execution  module  of  an  automaton  Ai  for  every  t  €  I.  Notice  that  y 
is  a  schedule  of  SC  iff  y  is  the  schedule  of  an  execution  z  of  fit  £«•  Lemma  4  implies 
this  is  the  case  iff  y  is  the  schedule  of  an  execution  z  of  []•  -A,  such  that  z| Ei  =  x,  is  an 
execution  of  E,  for  every  »  £  I.  Lemma  2  implies  this  is  the  case  iff  y\Ei  is  the  schedule 
of  an  execution  x,  of  Ei.  From  the  definition  of  schedule  module  composition  we  see 
this  is  the  case  iff  y  is  a  schedule  of  CS.  Thus,  SC  and  CS  have  the  same  schedules, 
and  hence  are  equal.  □ 

In  addition,  we  have  the  following. 

Lemma  7:  For  all  compatible  schedule  modules  {5,-  :  *  £  /}, 

External([l  Si)  =  External(Si). 

«€/  <6/ 

Proof:  Let  5  =  fli  $«»  and  let  EC  =  Extirnal[Y[i  S<)  and  CE  —  n<  External(Si).  Since 
the  schedule  modules  Si  are  compatible,  n  acts(Sj)  =  0  for  all  *  /  j.  That  is, 

the  internal  actions  of  each  schedule  module  are  disjoint  from  the  actions  of  the  others. 
With  this  observation,  it  follows  from  the  definition  of  action  signature  composition 
that  EC  and  CE  have  the  same  action  signature.  We  need  only  show  they  have  the 
same  schedules.  If  y  is  a  schedule  of  EC,  then  y  =  y'|ezt(5)  for  some  schedule  y* 
of  5.  Since  y'IS,  is  a  schedule  of  S<,  y| External (S,)  =  y'\ExternaI{Si)  is  a  schedule  of 
External  (Si),  and  hence  y  is  a  schedule  of  CE.  Conversely,  suppose  y  is  a  schedule  of 
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CE.  Then  y| External (S,)  =  y*|ext  (S<)  for  some  schedule  y,  of  Si.  Suppose  y  =  _ 

Let  us  write  y,  =  a^0\a\ . . .  where  a*  is  a  (possibly  empty)  sequence  of  internal  actions 
of  Si,  and  is  x,  if  xy  is  an  external  action  of  Si  and  the  empty  string  otherwise.  Let 
y*  =  la* . . .  where  ~tj  is  an  arbitrary  interleaving  of  the  actions  appearing  in  the  a). 
Then  y'  is  a  sequence  of  actions  of  S  such  that  y'jS,-  =  y<  is  a  schedule  of  Si,  so  y*  is  a 
schedule  of  5.  Since  y  =  y'lext(S),  y  is  a  schedule  of  EC.  □ 

Lemmas  S,  6,  and  7  can  be  summarized  as  follows. 

Corollary  8:  Let  A  denote  the  class  of  automata,  t  denote  the  class  of  execution 
modules,  and  S  denote  the  class  of  schedule  modules.  The  following  diagram  commutes: 


Eztca  -  Scheds  _  c  External 


A - 

n 

n 
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n 

,  Execs 
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Scheds 
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External 

>  . 

One  important  consequence  of  Corollary  8  is  the  following  result,  which  says  that 
the  (unfair)  behavior  of  a  composition  is  the  composition  of  its  components’  (unfair) 
behaviors. 

Lemma  0:  Ubth{  []  O,)  =  fl  Ubeh(Oi)  for  all  compatible  objects  {O,  :  i  €  /}. 

•€/  *€/ 

It  is  now  possible  to  see  that  composition  satisfies  a  number  of  natural  axioms.  We 
note  that  the  following  result  is  an  immediate  consequence  of  the  definition  of  schedule 
module  composition. 

Lemma  10:  Suppose  S  =  n<  S«»  T  =  lit  C/  =  I"I«  V  —  IL  Vs  where  the  5,, 

Ti,  Uit  and  Vi  are  schedule  modules. 

1.  S  T  =  T’S. 

2.  (5  •  r)  •  u  =  s  •  (r  •  u). 

3.  If  S  =  T  and  U  =  V,  then  S  •  U  =  T  •  V  whenever  the  compositions  5  •  U  and 
T  •  V  are  defined. 


As  a  consequence  of  Lemmas  9  and  10,  we  have  the  following. 


Lemma  11:  Suppose  O  =  Hi  Of,  P  =  ftPi,  Q  =  n<Q<,  end  R  =  ftP,  where 
the  Oi,  Pi,  Qi,  and  P,  are  objects. 


1  0  p  unfair  p  Q 

2.  (O  •  P)  •  Q  O  .  (P  •  Q). 

3.  If  0  u"— <Mf  P  and  Q  u"— **r  R,  then  0  •  Q  u"— **r  P  •  R  whenever  the  compositions 
O  •  Q  and  P  •  P  are  defined. 

Proof:  Recall  that  O  •  P  un— a'r  P  •  O  iff  the  external  schedule  modules  Ubeh(0  •  P)  and 
Ubeh(P  •  O)  are  equal.  By  Lemma  9  we  see  that  Ubeh{0  •  P)  =  Ubeh(0)  •  Ubeh(P)  and 
Ubeh(P  •  O)  =  Ubeh(P)  •  Ub*h(0).  However,  Lemma  10  implies  that  these  schedule 
modules  are  equal.  Therefore,  O  ■  P  “"£a*r  p  .  O.  The  remaining  parts  are  similar.  □ 

Conditions  1  and  2  say  that  composition  is  commutative  and  associative  up  to 
equivalence.  Condition  3  says  that  composition  is  a  almost  congruence  with  respect  to 
composition.  However,  since  the  external  behavior  of  O  and  Q  contains  no  information 
about  the  internal  actions  of  O  and  Q,  their  external  behaviors  do  not  determine 
whether  they  are  compatible,  and  hence  whether  their  composition  is  defined.  Thus, 
equivalence  is  not  quite  a  congruence.  We  call  an  equivalence  satisfying  condition  3  a 
weak  congruence.  Notice  that  this  weakness  is  due  only  to  conflicting  internal  actions 
names,  actions  not  affecting  the  external  behavior  of  an  object.  In  Section  2.1.3  we  will 
see  how  to  perform  a  syntactic  renaming  of  internal  action  names  to  avoid  this  conflict 
without  affecting  the  external  behavior  of  the  object.  This  is  reminiscent  of  variable 
renaming  to  avoid  conflict  during  substitution  in  predicate  calculus. 

2.1.2  Action  Hiding 

Recall  that  composition  does  not  hide  actions  modeling  interprocess  communication: 
In  particular,  if  x  is  an  output  action  of  A  and  an  input  action  of  B  modeling  com¬ 
munication  from  A  to  B,  then  x  becomes  an  (external)  output  action  of  A  •  B.  Since 
this  communication  is  really  internal  to  the  system  A  •  B,  we  would  like  to  be  able  to 
hide  x  from  external  view,  to  transform  x  into  an  internal  action  of  A  •  B. 

Given  an  object  O  and  a  set  of  actions  E,  we  define  the  object  Hidcz{0)  to  be  the 
object  differing  from  O  only  in  that 

1.  in{H\dcz{P))  =  «'r»(0)  —  E, 

2.  out  (Hide  z{0))  =  out(O)  —  E,  and 

3.  int(Hidez{0))  =  int(0)  U  ( act»{0 )  H  E). 
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Since  the  hiding  operation  modifies  only  the  action  signature  of  an  object  (without 
modifying  its  executions  or  schedules),  we  have  the  following: 

Lemma  13:  For  all  automata  A,  execution  modules  E,  schedule  modules  5,  and  sets 
of  actions  E, 

1.  Eztca(Htdtz{A))  =  Hidez(Ezees(A)) 

2.  Sehed$(Hidez(E))  =  Hidet(Seheds(E )) 

3.  External  (Hidez(S ))  =  External  (Hide  z(External(S ))) 

Proof:  Parts  1  and  2  are  immediate  from  the  definition  of  the  hiding  operation.  Part  3 
follows  from  the  fact  that  y|(ext(5)  -  E)  =  (y|e*t(S))|(ex<  (5)  -E)  for  every  schedule  y. 

□ 


As  a  corollary  of  Lemma  12,  we  have  the  following: 

Corollary  13:  Let  A  denote  the  class  of  automata,  t  denote  the  class  of  execution 
modules,  and  5  denote  the  class  of  schedule  modules.  The  following  diagram  commutes: 
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Suppose  {Oi  :  i  €  /}  are  compatible  objects,  and  consider  their  composition  O. 
Suppose  that  k  is  an  action  of  0<  not  shared  by  O,  for  every  i  ^  j.  Intuitively,  if  * 
models  some  communication  internal  to  the  system  component  modeled  by  O,,  then 
whether  x  is  hidden  before  or  after  forming  the  composition  O  should  not  affect  the 
resulting  object.  This  intuition  is  formalized  in  the  following  result. 


Lemma  14:  Let  {O,  :  *  G  /}  be  a  collection  of  compatible  objects,  and  let  {£<  :  i  6  /} 

be  a  collection  of  sets  of  actions.  If  acti(Ot)  and  £y  are  disjoint  for  all  »  /  y,  then 

Hide u^(n  O,)  =  n  HideZi(Ot). 

*€/  •€/ 

Proof:  Let  HC  —  Hide^.^XHi  O,)  and  CH  =  Hi  Hidez^Ot).  First,  we  claim  that 
the  composition  HC  is  defined  iff  CH  is  defined.  Since  for  all  t  ^  j  the  intersection 
act*(Oi)  n  Lj  is  empty,  for  all  i  #  j  we  have 

out(0<)  n  ovt(Oj)  =  (oui(0<)  -  E<)  n  (oui(Oj-)  -  £,) 

=  out(HidtzXOi))  n  out(HideZi(Oj)) 

and 

int(Oj)  n  aets(Oj)  =  ( mt(0, )  U  (£,  n  octs(0<))l  n  (acte(Oy)  -  £,] 

=  int (Hides. (Oi))  D  aets(HidezJ(Oj)). 

It  follows  that  the  objects  are  compatible  iff  the  objects  Hidtz,(Oi)  are  compatible, 
and  hence  that  HC  is  defined  iff  CH  is  defined. 

Next,  we  claim  that  HC  and  CH  have  the  same  action  signatures,  and  it  will  follow 
that  HC  and  CH  are  equal.  Notice  that 

in(HC)  =  mfllOO  -  (J  Ey 
•€/  ye/ 

=  (U  -  U  ot*4(0,))  -  U  E* 

.6/  ye/  *e/ 

=  (U  »(0i)  -  u  E>)  -  (U  -  u  E>) 

•€/  ye/  *6/  ye/ 

=  U(«"(O.)-E0  -  U(^(Oy)-Sy) 

«€/  ye/ 

=  (J  »n(JKde£,(Oi))  -  U  out  (Hides  ^Oj)) 

•e/  ye/ 

=  m(JJ  H\dez,(Oi))  =  in(CH). 

•e/ 

The  fourth  equality  holds  since  aete(Oi)  n  E,  is  empty  for  all  i  #  j.  Similar  arguments 
show  that  out(HC)  =  out(CH)  and  int(HC)  =  int(CH).  Therefore,  HC  and  CH 
have  the  same  action  signature,  and  hence  are  equal.  □ 

2.1.3  Action  Renaming 

Our  definition  of  composition  makes  the  names  of  actions  quite  important.  In  particu¬ 
lar,  the  notion  of  object  compatibility  depends  entirely  on  the  names  of  actions  shared 


by  the  objects.  In  this  section,  we  define  an  operation  that  renames  actions.  With  this 
operation,  objects  can  be  made  compatible  by  renaming  conflicting  actions. 

An  action  mapping  f  is  an  injective  mapping  between  sets  of  actions.  Such  a 
mapping  is  said  to  be  applicable  to  an  object  O  if  the  domain  of  /  contains  the  ac¬ 
tions  of  0.  Action  mappings  are  extended  to  objects  in  the  obvious  way.  If  the 
action  mapping  /  is  applicable  to  an  automaton  A,  then  the  automaton  /(A)  is 
the  automaton  with  the  states  and  start  states  of  A;  with  the  input,  output,  and 
internal  actions  /(»n(A)),  f{out(A)),  and  /( int(A )),  respectively;  with  the  transi¬ 
tion  relation  {(a,  f{x),a')  :  (a,  x,a‘)  €  steps  (A)};  and  with  the  equivalence  relation 
{(/(*). /(*■'))  :  (»>*')  ^jnrt(A)}.  Since  /  is  iqjective,  the  partition  of  the  locally- 
controlled  actions  of  /(A)  is  guaranteed  to  be  an  equivalence  relation.  Objects  /(O ) 
are  defined  similarly  for  other  types  of  objects.  Such  an  object  /(O)  is  said  to  be  a 
renaming  of  O.  Since  renaming  affects  only  action  names,  the  following  result  is  easy 
to  see. 

Lemma  IS:  Let  /  be  an  action  mapping  applicable  to  the  automaton  A,  the  execution 
module  E,  and  the  schedule  module  5. 

1.  Exec»(f{A))  =  /{Exec* (A)) 

2.  Sched*{f{E))  =  f{Sek*d»{E)) 

3.  Ezternal{f(S))  —  f{Extemal{S)) 

In  addition,  since  action  mappings  are  injective,  it  is  easy  to  see  that  actions  may 
be  hidden  before  or  after  renaming: 

Lemma  10:  Hide /(E) (/(O))  =  f{Hid*z{0))  for  any  object  O  and  applicable  action 
mapping  /. 

Let  us  consider  how  renaming  interacts  with  composition.  Suppose  an  action  map¬ 
ping  /,  is  applicable  to  the  object  0,  for  every  i  €  /.  First,  notice  that  if  each  /,  maps 
some  output  action  of  0,  to  the  action  w,  then  the  /i(0«)  are  incompatible;  and 
FI.  /.(0i)  i*  not  be  defined  even  though  fit  O,  may  be.  Furthermore,  if  each  fi  maps  an 
action  x  to  a  different  action  xit  then  executions  of  []•  /i(0»)  may  have  no  relationship 
to  the  executions  of  0.  0*  since  the  objects  /i(0,)  may  no  longer  be  required  to  syn¬ 
chronize  on  the  actions  x,.  We  are  therefore  led  to  define  a  collection  {/,  :  »  6  /}  of 
action  mappings  to  be  compatible  if  for  all  actions  x,  and  x}  we  have  /,(*,)  =  /,(»,)  iff 
xt  =  x, .  We  define  their  composition  f  =  W,  ft  to  be  the  action  mapping  having  as  its 
domain  the  union  of  the  domains  of  the  /,,  and  mapping  the  action  x  to  f,(x)  if  x  is 
in  the  domain  of  /,.  The  fact  that  the  /,  are  compatible  ensures  that  /  is  well-defined 
It  is  obvious  that  if  each  /,  is  applicable  to  an  object  O, ,  then  /  is  applicable  to  their 


composition.  In  addition,  the  following  result  verifies  that  the  renaming  of  such  objects 
may  occur  either  before  or  after  the  formation  of  their  composition  without  affecting 
the  resulting  object. 

Lemma  17:  Let  {O,  :  i  €  /}  be  compatible  objects,  and  let  {/<  :  i  €  /}  be  compatible 

action  mappings.  If  /,  is  applicable  to  O,  for  every  »  6  /,  then  ( FI  /•)(  II  0«)  =  II  /.(O,). 

•€/  i€I  •€/ 

Proof:  We  prove  the  result  for  automata  A.;  the  proofs  for  other  types  of  objects  are 
similar.  Let  /  =  n.  /«,  A  =  fl<  A«,  and  A '  =  n<  /i(A«).  We  show  that  /(A)  is  defined 
iff  A '  is  defined,  and  that  in  this  case  f(A)  =  A'.  To  do  so,  we  must  verify  the  following: 
(i)  that  the  A*  are  compatible  iff  the  fi(Ai)  are  compatible,  (ii)  that  f(A)  and  A'  have 
the  same  states  and  start  states,  (iii)  that  /(A)  and  A'  have  the  same  action  signature, 
(iv)  that  f(A)  and  A'  have  the  same  transition  relation,  and  (v)  that  f[A)  and  A '  have 
the  same  partition  of  locally-controlled  actions.  Since  the  /,  are  injective  mappings 
such  that  /,(*,)  =  fj(xj)  iff  *i  =  the  only  nontrivial  part  of  this  proof  to  check  is 
part  (iv).  Suppose  that  (a,  »,a')  is  a  step  of  f{A).  For  some  action  o  we  must  have 
that  (a,  o,  a')  is  a  step  of  A ,  and  that  f(o)  =  k.  Furthermore,  for  each  t,  the  action  a 
is  an  action  of  A,  iff  *  is  an  action  of  /^(A*).  If  it  is  an  action  of  /.(.A,),  then  a  is 
an  action  of  A,,  so  (a|A^,<r,a'|A,)  is  a  step  of  A,  and  (a|/,(A*),ir,a|/,(A*))  is  a  step  of 
/.(A,).  If  w  is  not  an  action  of  /<(A,),  then  a  is  not  an  action  of  A«,  so  a|A<  =  a'|A« 
and  a|/,(A0  =  o'|/<(A,).  In  either  case,  (a,*, o')  is  a  step  of  A'  =  fl.  A(A^).  A  similar 
argument  shows  that  if  (a,  *,a')  is  a  step  of  A',  then  it  is  a  step  of  /(A).  It  follows  that 
/(A)  and  A'  have  the  same  transition  relation,  and  hence  are  equal.  □ 

2.1.4  Remarks 

Since  the  definitions  given  so  far  have  been  independent  of  such  considerations,  we 
have  chosen  to  ignore  until  this  point  issues  of  cardinality  that  appear  in  most  mod¬ 
els  of  computation.  For  example,  we  have  not  restricted  our  model  to  automata  with 
countable  sets  of  states  and  actions,  and  hence  to  countable  nondeterminism.  Fur¬ 
thermore,  we  have  not  restricted  our  theory  to  the  composition  of  a  finite  (or  even 
countable)  number  of  automata.  While  these  are  natural  restrictions  (and  all  of  the 
results  presented  thus  far  still  hold  when  these  restrictions  are  imposed),  we  note  that 
Lynch  and  Merritt  have  made  effective  use  of  the  composition  of  a  countable  number 
of  automata  in  [LM86J.  In  the  remainder  of  this  thesis,  we  restrict  our  attention  to 
automata  modeling  systems  with  a  countable  number  of  components.  In  particular,  we 
restrict  our  attention  to  countable  compositions,  and  to  automata  A  for  which  part  (A) 
partitions  A’s  locally-controlled  actions  into  a  countable  number  of  equivalence  classes. 
This  restriction  becomes  relevant  in  the  following  section  where  we  define  the  notion 
of  fair  computation. 
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2.2  Fairness 

Fair  computation  is  of  central  importance  to  distributed  computation.  The  mutual 
exclusion  problem,  for  example,  has  been  formulated  in  [EM72]  with  the  “no  lockout* 
condition  that  if  every  process  is  allowed  to  take  steps  infinitely  often,  then  every 
process  trying  to  enter  its  critical  region  will  eventually  do  so.  That  is,  during  fair 
computation,  every  process  wishing  to  enter  its  critical  region  will  eventually  do  so. 
More  generally,  the  specification  of  a  distributed  system  typically  includes  conditions 
of  the  form  “if  condition  P  holds,  then  eventually  condition  Q  will  hold*  The  ability 
of  a  process  to  satisfy  such  conditions  clearly  depends  on  fair  computation.  In  this 
section  we  show  how  fair  computation  can  be  described  in  our  model,  and  we  show 
how  fair  computation  induces  an  interesting  equivalence  of  automata. 

2.2.1  Fair  Executions 

As  previously  mentioned,  computation  in  a  system  of  processes  is  said  to  be  fair  if 
every  process  is  given  the  chance  to  make  computational  progress  infinitely  often.  The 
phrase  “given  the  chance”  is  important,  since  a  process  may  not  be  in  a  position 
to  make  progress  every  time  it  is  given  the  chance.  Recall  that  associated  with  an 
automaton  A  is  a  partition  part  {A)  of  its  locally-controlled  actions.  Intuitively,  each 
class  of  this  partition  consists  of  the  locally-controlled  action  of  a  process  in  the  system 
being  modeled  by  A.  A  fair  execution  of  an  automaton  A  is  defined  to  be  an  execution  z 
such  that  the  following  conditions  hold  for  each  class  C  of  part  (A): 

1.  If  x  is  a  finite  execution,  then  no  action  of  C  is  enabled  from  the  final  state  of  z. 

2.  If  x  is  an  infinite  execution,  then  either  actions  from  C  appear  infinitely  often 
in  z,  or  states  from  which  no  action  of  C  is  enabled  appear  infinitely  often  in  z. 

These  conditions  may  be  interpreted  as  follows.  If  z  is  finite,  then  computation  in  the 
system  has  halted  since  no  process  is  able  to  take  another  step.  If  z  is  infinite,  then 
every  process  has  been  given  the  chance  to  take  a  step  infinitely  often,  although  it  may 
be  that  some  process  was  unable  to  make  computational  progress  every  time  it  was 
given  the  chance  to  do  so.  Notice  that  this  definition  of  fairness  is  essentially  what  is 
called  weak  fair  nets  in  the  literature  (see  [FraM],  for  example).  As  mentioned  in  the 
introduction,  however,  our  definition  is  different  in  an  important  way  in  that  it  takes 
into  consideration  the  notion  of  one  process  controlling  the  performance  of  an  action 
In  particular,  it  is  possible  for  an  (input)  action  to  be  continuously  enabled,  and  yet 
never  be  performed.  We  note  in  passing  that  our  notion  of  fairness  defines  the  notion 
of  a  finite  fair  computation  without  the  usual  requirement  that  finite  computations  be 
extended  in  some  trivial  way  to  infinite  computations. 
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The  set  fair  (A)  is  the  eet  of  fair  execution*  of  the  automaton  A ,  and  Fo»r(A)  i*  the 
execution  module  of  A  having  fair  (A)  a a  it*  aet  of  execution*. 

One  simple  consequence  of  this  definition  of  fair  execution*  is  the  following. 

Lemma  It:  If  x  is  a  finite  execution  of  an  automaton  A,  then  x  can  be  extended  to 
a  fair  execution  xxiai .  .  .  of  >4  (in  which  every  x,  is  a  locally-controlled  action  of  A). 

Proof:  Let  /  be  a  function  mapping  the  natural  numbers  to  the  classes  of  part  (A), 
with  the  property  that  every  class  of  part  (A)  appears  in  the  range  of  /  infinitely  often. 
There  is  an  execution  if  -  xx1a1 . . .  of  A  with  the  property  that  x,  is  an  action  from  the 
class  /( »)  if  such  and  action  is  enabled  from  a*_i,  and  an  arbitrary  locally-controlled 
action  of  A  otherwise.  (If  from  some  state  o,_i  no  locally-controlled  action  of  A  is 
enabled,  then  if  is  a  finite  execution  ending  in  state  a*_|.)  The  execution  if  is  a  fair 
execution  of  A.  □ 

More  important,  however,  is  the  next  lemma  which  says  that  the  fair  executions  of 
a  composition  are  a  composition  of  the  fair  executions  of  its  components.  It  is  for  the 
sake  of  this  result  that  we  associate  a  partition  of  an  automaton’s  locally-controlled 
actions  with  an  automaton. 

Lemma  10:  /Yur(n  A,)  =  f]  Fair  (A,)  for  all  compatible  automata  (A,  :  i  €  /}. 

•€/  •€/ 


Proof:  Let  FC  =  Foir(n.A,)  and  CF  =  n.  Fair  (A,).  Since  both  are  execution 
modules  of  A  -  n.  A,,  both  have  the  same  states  and  action  signature.  We  need  only 
show  that  they  have  the  same  executions.  First,  however,  notice  that  since  the  A, 
are  compatible,  their  locally-controlled  actions  are  disjoint.  Furthermore,  notice  that 
each  A  is  input-enabled.  It  follows  that  each  A  determines  when  its  locally-controlled 
actions  are  enabled  in  the  composition  A:  If  x  is  a  locally-controlled  action  of  A  and  a 
is  a  state  of  A,  then  x  is  enabled  from  a  in  A  iff  x  is  enabled  from  e|A«  in  A- 

Suppose  x  is  a  fair  execution  of  A,  and  let  us  show  that  x  is  an  execution  of  C  F 
We  must  show  that  x \A  i*  *  fair  execution  of  A,  for  all  *.  Let  C  be  a  class  of  locally- 
controlled  actions  of  A,  and  hence  a  class  of  A.  Suppose  x  is  finite.  Since  x  is  a  fair 
execution  of  A,  no  action  of  C  is  enabled  in  A  from  the  final  state  a  of  x,  and  hence 
no  action  of  C  is  enabled  in  A  from  the  final  state  ejA,  of  x|A,.  Suppose  x  is  infinite. 
If  actions  from  C  appear  infinitely  often  in  x,  they  do  so  in  x|A,.  On  the  other  hand, 
suppose  states  appear  infinitely  often  in  x  from  which  no  action  of  C  is  enabled  in  A 
It  follows  that  either  x|A,  is  finite  and  no  action  of  C  is  enabled  from  the  final  state  of 
z  A  in  A,,  or  else  infinitely  many  states  of  A  appear  in  x!  A  from  which  no  action  of  C 
is  enabled.  In  any  case,  r  A,  is  a  fair  execution  of  A,.  It  follows  that  x  is  an  execution 
of  CF. 
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Conversely,  suppose  *  is  an  execution  of  CF ,  and  let  us  show  that  z  is  a  fair 
execution  of  A.  Let  C  be  a  class  of  locally-controlled  actions  of  A ,  and  therefore  a  class 
of  A^  for  some  i.  Since  2  is  an  execution  of  CF,  the  execution  z\A,  is  a  fair  execution 
of  Ai.  Suppose  x  is  finite,  and  therefore  that  x|j4<  is  finite.  Since  is  fair,  no  action 
of  C  is  enabled  from  the  final  state  of  z|j4«,  and  hence  no  action  of  C  is  enabled  from 
the  final  state  of  x.  Suppose  z  is  infinite.  If  actions  from  C  appear  infinitely  often 
in  x\A,,  the  same  is  true  of  z.  If  states  appear  infinitely  often  in  z|j4»  from  which  no 
action  of  C  is  enabled,  the  same  is  true  in  z.  However,  x\Ai  may  be  finite.  In  this 
case,  no  action  of  C  is  enabled  from  the  final  state  of  x\A 4.  Since  z  is  infinite,  there  is 
a  state  appearing  in  z  after  which  no  action  of  C  is  ever  enabled.  In  any  case,  z  must 
be  a  fair  execution  of  A.  It  follows  that  FC  =  CF.  □ 


2.2.2  Fair  Equivalence 

In  Section  2.1  we  defined  a  notion  of  equivalence  based  on  the  external  behavior  of 
an  object.  We  now  define  a  similar  notion  of  equivalence  baaed  on  fair  external  be¬ 
havior.  The  fair  behavior  of  an  automaton  A ,  denoted  by  Fbek(A),  is  defined  to  be 
the  schedule  module  Ezternal(Fair(A)).  We  extend  this  definition  to  objects  of  other 
types  (execution  modules  and  schedule  modules)  by  setting  Fbeh(0)  —  Ubeh(0).  It  is 
convenient  to  denote  the  set  of  schedules  of  Fbek(0)  by  fbeh(O),  for  any  object  O.  In 
light  of  Corollary  8  and  Lemma  10,  we  see  that  the  fair  behavior  of  a  composition  is 
the  composition  of  the  fair  behavior  of  its  components. 

Umnu  20:  Fb*h{  f|  O,)  =  n  Fbeh{Ot)  for  compatible  objects  {O*  :  i  €  /}. 

•€/  *€/ 


We  say  that  two  objects  O  and  O'  are  fairly  equivalent ,  denoted  O  f=r  O',  if  they 
have  the  same  fair  behavior;  that  is,  if  FbeH[0)  =  Pfceh(O').  In  light  of  Lemmas  10 
and  20,  fair  equivalence  satisfies  the  axioms  stated  for  unfair  equivalence  in  Lemma  11. 

Lemma  21:  Suppoee  O  =  F1.  0..  P  *  IL  F,  Q  =  *ad  A  =  II where 

the  O,,  P,,  Qi ,  and  A*  are  objects. 

1.  O  Pf=  P  O. 

2.  (O  P)  Qf=  O  (P  Q). 

3.  If  O  f='  P  and  Q  R,  then  O  •  Q  f=*  P  ■  R  whenever  the  compositions  O  Q 
and  P  R  are  defined. 
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Figure  2.2:  The  importance  of  the  partition  of  locally-controlled  actions. 


Thus,  composition  is  commutative  and  associative  up  to  fair  equivalence,  and  fair 
equivalence  is  a  weak  congruence  with  respect  to  composition.  With  this  we  conclude 
that  discussion  of  fairness  directly  related  to  program  verification.  In  the  remainder  of 
this  section  we  consider  several  interesting  questions  about  how  fairness  is  modeled  in 
our  model. 


2.2.3  Fairness  and  System  Decomposition 


Having  seen  the  definition  of  a  fair  execution,  the  role  of  the  equivalence  relation 
part  (A)  associated  with  an  automaton  A  is  clear:  The  automaton  models  a  system, 
and  the  locally-controlled  actions  of  each  system  component  form  a  separate  class  of 
the  partition.  It  is  worth  considering,  however,  whether  this  partition  is  really  of  any 
importance.  We  claim  that  if  relationships  such  as  those  stated  in  Lemma  20  are  of 
importance  (and  we  think  they  are),  then  the  information  about  the  system  structure 
encoded  in  the  partition  of  an  automaton’s  locally-controlled  actions  must  be  retained. 
Suppose  for  a  moment  that  we  do  away  with  the  partition,  so  that  all  we  know  about 
an  automaton’s  locally-controlled  action  is  whether  it  is  an  internal  or  output  action. 
Consider  the  automata  A  and  B  given  in  Figure  2.2,  and  consider  their  composition 
A  ■  B.  Here  a  is  an  input  action,  and  0  and  7  are  output  actions.  In  both  automata  A 
and  B,  the  execution  with  the  infinite  sequence  of  a’s  as  its  schedule  may  be  considered 
a  fair  execution  since  infinitely  often  each  automaton  passes  through  a  state  from  which 
no  locally-controlled  action  (either  0  or  7)  is  enabled.  In  the  composition,  however,  a 
locally-controlled  action  is  enabled  from  every  state  through  which  such  an  execution 
must  pass,  and  yet  none  of  these  actions  appear  in  the  execution.  This  execution  cannot 
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be  considered  a  fair  execution  of  the  system  since  the  system  is  never  allowed  to 
progress,  even  though  it  is  able  to  do  so  at  each  stage  of  the  execution.  If,  on  the  other 
hand,  we  recognise  that  0  and  are  output  actions  of  separate  system  components,  we 
see  that  infinitely  often  each  component  passes  through  a  state  from  which  none  of  its 
locally-controlled  actions  is  enabled.  We  therefore  conclude  that  this  t#  an  execution  of 
the  system  that  is  fair  to  all  components,  and  hence  can  be  considered  a  fair  execution 
of  the  system.  The  partition  of  locally-controlled  actions  therefore  seems  to  be  an 
important  component  of  an  input-output  automaton. 

It  is  conceivable,  however,  that  an  automaton’s  actions  can  be  partitioned  in  such  a 
way  that  it  is  impossible  for  the  automaton  to  model  a  system  whose  components  have 
as  their  locally-controlled  actions  one  class  of  the  partition.  It  therefore  seems  possible 
for  our  intuitive  understanding  of  an  automaton’s  partition  of  its  locally-controlled 
actions  to  be  violated.  Let  us  say  that  an  automaton  A  is  primitive  if  part  (A)  consists 
of  a  single  class.  Intuitively,  such  an  automaton  can  model  only  an  “atomic’’  system 
component.  It  would  be  nice  to  know  that  every  automaton  A  is  (fairly)  equivalent 
to  a  composition  of  primitive  automata,  where  the  locally-controlled  actions  of  each 
primitive  automaton  form  a  class  of  A’s  partition.  This  would  in  effect  be  saying  that 
every  automaton  does  model  a  system  in  a  way  satisfying  our  intuition.  What  we  can 
prove  is  the  following.  An  automaton  is  said  to  be  deterministic  if  it  has  one  start 
state,  and  for  every  action  x  there  is  at  most  one  x-step  from  every  state. 

Lemma  22:  Let  A  be  an  automaton  whose  equivalence  relation  part  {A)  partitions  its 
locally-controlled  actions  into  the  classes  {C,  :  i  6  /}.  If  A  is  deterministic,  then  there 
are  primitive  automata  A*  such  that  C<  is  the  set  of  locally-controlled  actions  of  A,, 
and  A  f=  HidelKt{A)(U  A«). 

t€J 
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Proof:  Since  A  —  Hideint^A)(A')  where  A !  is  the  automaton  differing  from  A  only  in 
that  the  internal  actions  of  A  are  output  actions  of  A',  we  may  assume  without  loss  of 
generality  that  A  has  no  internal  actions,  and  show  that  A  —  n«  A,-  Let  A,  be  the 
primitive  automaton  obtained  from  A  as  follows.  First,  set  m(A«)  =  acts  (A)  -  C,  and 
out  (A,)  =  C,.  Second,  add  to  A,  a  dead  state  d.  Finally,  to  ensure  that  A«  is  input- 
enabled,  if  w  is  an  input  action  that  is  not  enabled  from  a  state  a,  add  the  transition 
a  A  d  from  a  to  the  dead  state  d.  Let  B  =  n»  A*-  We  claim  that  A  f=  B. 

Suppose  x  is  a  fair  execution  of  A.  Since  x  is  also  an  execution  of  each  A«,  there  is 
an  execution  y  of  B  such  that  y|A«  =  x  for  every  ».  We  claim  that  y  is  a  fair  execution 
of  B.  If  actions  from  (7,  appear  infinitely  often  in  x,  then  the  same  is  true  of  y.  On 
the  other  hand,  suppose  that  r  is  an  action  of  C<  that  is  not  enabled  from  a  state  a 
of  A.  Then  x  is  an  (output)  action  of  A,  that  is  not  enabled  from  the  state  a  in  A*,  and 
hence  not  from  the  state  (a)  in  B.  It  follows  that  if  x  is  finite  and  no  action  from  C,  is 
enabled  from  the  final  state  of  x,  then  the  same  is  true  of  y;  and  that  if  x  is  infinite  and 


there  are  infinitely  many  states  appearing  in  z  from  which  no  action  of  C,  is  enabled, 
then  the  same  is  true  of  y.  Therefore,  y  is  a  fair  execution  of  B. 

Conversely,  suppose  y  is  a  fair  execution  of  B.  We  claim  that  z  =  y| A,  is  a  fair 
execution  of  A  for  every  t.  We  will  soon  show  that  if  b  is  a  reachable  state  of  B,  then 
all  components  b\A+  of  b  are  equal,  and  equal  to  a  state  other  than  d.  From  this  it 
will  follow  that  all  y\A*  are  equal.  Furthermore,  since  z  =  yjA,-,  the  state  d  must  not 
appear  in  z.  Since  transitions  to  d  were  the  only  transitions  added  in  the  construction 
of  At,  x  is  an  execution  of  A.  Furthermore,  since  z  is  fair  in  A,,  either  z  is  finite  and  no 
action  of  C,  is  enabled  from  the  final  state  of  z;  or  z  is  infinite  and  either  actions  of  C, 
appear  infinitely  often  in  z,  or  states  appear  infinitely  often  in  z  from  which  no  action 
of  Ci  is  enabled.  Since  this  is  true  for  every  class  Ci,  z  is  must  be  a  fair  execution  of  A. 

We  now  proceed  by  induction  on  the  length  t  of  an  execution  required  to  reach  b  to 
show  that  b\Ai  =  b\Aj  #  d  for  all  *  and  j.  Since  A  has  a  single  start  state,  each  A,  has 
the  same  (unique)  start  state,  and  the  case  of  t  =  0  is  trivial.  Suppose  i  >  0  and  the 
inductive  hypothesis  holds  for  t  —  1.  Suppose  b  is  reachable  by  an  execution  of  length  l 
whose  last  transition  is  V  b.  Since  bf  is  reachable  by  an  execution  of  length  l  —  1, 
the  inductive  hypothesis  implies  that  VjA«  =  V\Aj  #  d  for  all  t  and  j.  Since  ir  is  either 
an  input  action  of  A  or  an  output  action  of  A  (and  hence  of  some  A*),  there  must  be 
an  automaton  A,  for  which  no  transition  V\Ai  d  was  added  during  its  construction. 
It  follows  that  V) A,  —>  6|A«  must  be  a  transition  of  A,  and  hence  that  no  dead  state 
transition  was  added  from  V|A,  during  the  construction  of  any  Ay.  Therefore,  every 
step  V\Ai  A  b\Ai  is  a  step  of  A.  Since  A  is  deterministic,  there  is  only  one  such  step, 
so  b\Ai  =  b\Af  /  d  for  all  t  and  j.  □ 

This  result  says  that  our  intuition  (our  understanding  of  an  automaton’s  partition 
of  its  locally-controlled  actions)  is  satisfied  by  a  very  restricted  class  of  automata.  It 
does  not  seem  to  be  true,  however,  for  arbitrary  automata  (although  Lemma  22  does 
hold  for  arbitrary  automata  if  fair  equivalence  is  replaced  by  unfair  equivalence,  the 
proof  of  this  using  the  same  construction  as  in  the  proof  of  Lemma  22).  The  reason  the 
construction  given  above  will  not  work  for  nondeterministic  automata  is  clear:  The  ex¬ 
istence  of  nondeterminism  allows  the  components  to  diverge  during  computation.  Each 
component  may  then  pass  through  states  from  which  none  of  its  locally-controlled  ac¬ 
tions  are  enabled,  from  which  it  follows  that  no  locally-controlled  actions  appear  in  the 
executions  generated  by  any  of  the  components.  Since,  however,  each  component  may 
pass  through  states  from  which  all  locally-controlled  actions  of  all  remaining  compo¬ 
nents  are  always  enabled,  none  of  the  executions  generated  by  any  of  the  components 
are  fair  executions  of  the  original  automaton  A,  whose  classes  are  the  output  actions  of 
the  component  automata.  What  is  obviously  required  is  a  coordinator  or  scheduler  S  to 
ensure  that  all  automata  choose  the  same  transition  at  every  step.  With  this  intuition 
in  mind,  we  now  prepare  to  show  the  following. 

Theorem  23:  Let  A  be  an  automaton  whose  equivalence  relation  part  (A)  partitions  its 
locally-controlled  actions  into  the  classes  {Ci  :  »  €  /}.  There  are  primitive  automata  A, 
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and  5  such  that  C<  ia  the  set  of  locally-controlled  actions  of  A«,  E  is  the  set  of  locally- 

controlled  actions  of  S,  and  A  f=  H»dejnl(A)uE(  n  A<  ■  S). 

*€/ 

The  primitive  automata  A*  used  in  this  construction  are  essentially  the  primitive 
automata  used  in  the  proof  of  Lemma  22.  However,  when  the  Ai  perform  an  action,  the 
scheduler  5  must  be  able  to  direct  all  of  them  to  take  the  same  step.  These  directions 
take  the  form  of  certain  input  actions  of  the  A,-,  where  the  performance  of  such  >>n  action 
by  the  scheduler  tells  the  component  automata  which  transition  they  are  supposed  to 
make.  We  add  these  actions  to  the  A,  (although  initially  as  internal  actions)  with  the 
following  result. 

Lemma  24:  For  every  automaton  A,  there  is  a  deterministic  automaton  B  such  that 
A  B.  The  locally-controlled  actions  of  B  are  partitioned  into  the  classes  of  A, 
together  with  an  additional  class  £  of  internal  actions. 

Proof:  For  ease  of  exposition,  we  construct  a  nondeterministic  automaton  B,  and  then 
show  how  it  can  be  transformed  into  an  equivalent  deterministic  automaton.  The  states 
of  B  are  of  the  form  (a,  a)  where  a  is  a  state  and  a  is  a  (possibly  empty)  sequence  of 
actions.  The  start  state  of  B  is  (s, «),  where  s  is  a  distinguished  state  (not  a  state  of  A) 
and  e  is  the  empty  sequence  of  actions.  The  states  of  B  are  (a,  a)  and  («,  a),  where  a  is 
a  state  of  A  and  a  is  a  (possibly  empty)  sequence  of  actions  of  A.  The  action  signature 
and  partition  of  B  are  precisely  those  of  A,  except  that  an  additional  scheduling  action  x 
(an  internal  action)  forms  its  own  class  of  fl’s  partition.  The  transitions  of  B  from  a 
state  (a,  a),  where  a  is  a  state  of  A,  are  as  follows: 

(a,  a)  (o',  e)  in  B  iff  a  o'  in  A 
(a,  a)  A  (o,  olo)  in  B  iff  o  ?  o'  in  A  for  some  o' 

That  is,  x  determines  what  transitions  A  actually  makes  from  the  state  a  when  the 
sequence  of  actions  a  is  actually  performed.  All  other  actions  are  simply  recorded  as 
actions  to  be  performed  by  A  at  a  later  time.  The  transitions  of  B  from  a  state  (a,  a) 
are  as  follows: 

(s,  a)  (o,f)  in  B  iff  ao  A  a  in  A  for  some  start  state  ao 
(s,  a)  (s,  air)  in  B  iff  o  is  an  input  action  of  A 

In  this  case,  only  input  actions  and  x  are  enabled  from  a  state  of  the  form  (a,  a).  In 
this  way,  fair  computation  will  guarantee  that  x  is  eventually  performed,  and  hence 
that  an  initial  state  is  chosen  for  A.  Thus,  the  scheduling  action  x  chooses  the  initial 
state  of  A,  as  well  as  the  steps  taken  by  A  during  computation.  We  claim  tha'  A  f=T  B. 
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Suppose  that  A ’a  locally-controlled  actions  are  partitioned  into  the  classes  {C<  :  i  6  /}. 
These  classes  together  with  the  class  {x}  are  the  classes  of  B. 

Let  x  be  a  fair  execution  of  A.  Let  y  be  the  execution  of  B  obtained  by  replacing 
each  transition  a  A  a'  of  x  by  the  transitions  (a,e)  A  (a,o)  (a',<),  followed  by 

the  infinite  sequence  of  transitions  (a,  c)  —*  (a,  e)  •  •  •  in  the  case  that  x  is  a  finite 
execution  ending  in  the  state  a.  Suppose  x  is  finite.  Since  x  is  fair,  no  locally-controlled 
action  is  enabled  in  A  from  the  final  state  a  of  x.  It  follows  that  no  locally-controlled 
action  of  B  is  enabled  from  any  of  the  infinite  occurrences  of  (o,  e)  in  y,  except  for  x 
which  occurs  infinitely  often.  Hence,  y  is  a  fair  execution  of  B.  Conversely,  suppose 
that  x  is  infinite.  Since  x  is  fair,  for  each  class  C*  either  actions  from  appear  infinitely 
often  in  x,  or  from  infinitely  many  states  appearing  in  x  no  action  from  C,  is  enabled. 
In  the  first  case,  actions  from  C,-  appear  infinitely  often  in  y.  In  the  second  case,  since 
an  action  a  is  enabled  from  a  state  a  of  A  iff  it  is  enabled  from  (a,  e)  in  B,  infinitely 
many  states  appear  in  y  from  which  no  action  of  C,-  is  enabled.  Since,  in  addition,  x 
appears  infinitely  often  in  the  execution,  y  must  be  a  fair  execution  of  B. 

Conversely,  let  y  be  a  fair  execution  of  B.  From  the  definition  of  B  we  see  that 
if  (a, c)  (a,0i*--on)  (a',e)  is  a  sequence  of  transitions  in  B,  then 

a  ^  aj  •  •  •  ^  o'  is  a  sequence  of  transitions  of  A.  In  addition,  if  (e,c)  ^  (e,oi)  •  •  •  ^ 
(e,Oi  — »  (o, e)  is  a  sequence  of  transitions  in  B,  then  ao  ^  «!•••  ^  a  is  a 

sequence  of  transitions  of  A  for  some  start  state  ao  of  A.  Let  x  be  the  execution 
of  A  obtained  by  replacing  every  such  sequence  in  y  by  the  corresponding  sequence  of 
transitions  of  A.  Since  y  is  fair,  the  action  x  must  appear  infinitely  often  in  y,  and 
hence  y  must  be  infinite.  If  actions  from  C<  appear  infinitely  often  in  y,  then  the  same 
is  true  in  x.  If  not,  then  there  are  infinitely  many  states  appearing  in  y  from  which  no 
action  of  C,  is  enabled.  Notice  that  if  an  action  a  other  than  x  is  not  enabled  from 
from  the  state  (a,  a)  in  B,  then  for  all  states  o'  of  A  such  that  a  a!  it  must  be  that  a 
is  not  enabled  from  a'.  It  follows  that  either  x  is  finite  and  no  action  of  C,  is  enabled 
from  the  final  state  of  x,  or  there  are  infinitely  many  states  appearing  in  x  from  which 
no  action  of  C,  is  enabled.  In  either  case,  x  must  be  a  fair  execution  of  A. 

We  have  just  shown  that  A  f=  B.  However,  we  are  not  yet  done  since  B  is  not 
yet  deterministic:  There  are  potentially  many  x-steps  from  every  state  of  B.  However, 
we  cam  assign  to  each  x-step  a  unique  identifier,  and  tag  the  x  labeling  the  step  with 
this  identifier.  Replacing  the  action  x  with  the  set  E  of  newly-tagged  x’s,  it  is  easy 
to  see  that  this  automaton  is  fairly  equivalent  to  B,  and  hence  also  to  A.  Since  this 
automaton  is  a  deterministic  automaton  (with  an  extra  class  £  of  internal  actions) ,  we 
are  done.  □ 

We  are  now  able  to  prove  Theorem  23. 

Proof  of  Theorem  23:  Given  the  automaton  A,  construct  the  automaton  B  of 
Lemma  24.  The  automaton  B  is  fairly  equivalent  to  A,  and  its  locally-controlled 
actions  are  partitioned  into  the  same  classes  as  those  into  which  A’s  actions  are  par- 
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Figure  2.3:  Fur  equivalence  and  unfair  equivalence  are  incomparable. 


titioned,  together  with  an  additional  class  E  of  internal  actions.  Furthermore,  B  is  a 
deterministic  automaton.  Lemma  22  says  there  are  primitive  automata  A and  S  with 
local{Ai)  =  Ci  and  local  (S)  =  E  such  that  B  (and  hence  A)  is  fairly  equivalent  to 
A<  •  5),  which  is  just  J^tdeint(A)uE(rii  A,  ■  S).  □ 


2.2.4  Comparing  Fair  and  Unfair  Equivalence 


Having  defined  two  types  of  equivalence,  fair  equivalence  and  unfair  equivalence,  it  is 
natural  to  ask  how  they  are  related.  Since  Fbch(0)  —  Ubch(0)  when  O  is  an  execution 
module  or  schedule  module,  fair  and  unfair  equivalence  are  identical  for  execution 
modules  and  schedule  modules.  For  automata,  however,  they  are  incomparable. 

Consider,  for  example,  the  automata  of  Figure  2.3.  The  (primitive)  automata  A 
and  B  each  have  an  input  action  a  and  an  output  action  0.  The  unfair  behavior  of 
both  A  and  B  consists  of  all  sequences  of  a  and  0,  so  A  and  B  are  unfairly  equivalent. 
The  fair  behavior  of  A,  however,  includes  the  infinite  sequence  of  a’s.  Since  the  fair 
behavior  of  B  does  not,  A  and  B  are  fairly  inequivalent.  On  the  other  hand,  C  and  D  are 
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two  (nonprixnitive)  automata  with  output  actions  a  and  0,  each  forming  a  separate  class 
in  the  partition  of  the  locally-controlled  actions.  The  fair  behavior  of  C  and  D  consist 
of  finite  sequences  of  a’s  followed  by  a  0  and  an  infinite  sequence  of  a’s,  so  C  and  D 
are  fairly  equivalent.  The  unfair  behavior  of  C,  however,  includes  the  infinite  sequence 
of  a’s.  Since  the  unfair  behavior  of  D  does  not,  C  and  D  are  unfairly  inequivalent. 

Thus,  in  general,  fair  equivalence  and  unfair  equivalence  are  incomparable.  The 
following  lemma,  however,  indicates  that  fair  equivalence  implies  unfair  equivalence  in 
the  case  of  primitive  automata.  Since  the  primitive  automata  A  and  B  of  Figure  2.3  are 
unfairly  equivalent  but  not  fairly  equivalent,  we  see  that  fair  equivalence  is  a  stronger 
equivalence  that  unfair  equivalence  in  the  case  of  primitive  automata. 

Lemma  25:  Let  A  and  B  be  two  primitive  automata.  If  A  and  B  are  fairly  equivalent, 
then  A  and  B  are  unfairly  equivalent. 

Proof:  It  is  enough  to  check  that  acheda(A)\ezt(A)  =  achcda(B)\ext(B).  Suppose  x 
is  an  execution  of  A.  If  an  infinite  number  of  locally-controlled  actions  appear  in  x, 
then  since  A  is  a  primitive  automaton  (with  a  single  class  of  locally-controlled  ac¬ 
tions),  x  is  a  fair  execution  of  A.  Since  A  and  B  are  fairly  equivalent,  there  is  a  fair 
execution  y  of  B  such  that  ached(x)\ext(A)  =  ached  (y)\ext(B).  On  the  other  hand, 
if  only  a  finite  number  of  locally-controlled  actions  appear  in  x,  then  we  may  write 
x  =  x'x"  where  x*  is  a  finite  execution  of  A,  and  every  locally-controlled  action  ap¬ 
pearing  in  x  appears  in  X*.  By  Lemma  18,  the  finite  execution  x*  can  be  extended 
to  a  fair  execution  z  of  A.  Since  A  and  B  are  fairly  equivalent  there  is  a  fair  exe¬ 
cution  y  of  B  such  that  ached(z)\ext(A)  =  ached (y)\ ext (B).  Thus,  there  is  a  finite 
execution  ]/  of  £,  a  prefix  of  y,  such  that  ached(x?)\ext(A)  =  ached(y')\ext{B).  Since  B 
is  input  enabled  and  no  locally-controlled  action  appears  in  x  after  x1,  y1  may  be  ex¬ 
tended  to  an  execution  y"  of  B  such  that  ached  (x)|  ext  (A)  =  ached(y")\ext(B).  Thus, 
acheda(A)\ext[A)  C  acheda (B)\ext(B).  Since  the  opposite  containment  follows  by  a 
symmetric  argument,  we  are  done.  □ 


2.3  Hierarchical  Correctness  Proofs 

The  problem  motivating  this  thesis  is  the  construction  of  hierarchical  correctness  proofs 
for  distributed  algorithms.  We  have  already  mentioned  in  the  introduction  how  such  a 
proof  might  be  constructed.  First,  a  sequence  of  models  Oi, . . . ,  On  are  defined,  objects 
of  some  type  modeling  the  algorithm  at  decreasing  levels  of  abstraction.  Each  model  0< 
is  then  shown  to  “simulate”  0<_j  in  some  appropriate  sense  of  the  word  “simulate.”  In 
such  a  proof,  each  0,_i  can  be  viewed  as  the  statement  of  a  problem  O,  is  required  to 
solve.  Oi  may  be  said  to  solve  the  problem  specified  by  0,_i  if  every  behavior  of  0, 
is  a  behavior  of  Oi- Oi  solves  the  problem  specified  by  0*_i  in  the  sense  that  every 
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correctness  condition  satisfied  by  each  behavior  of  0,_  i  is  also  satisfied  by  each  behavior 
of  O,-.  However,  as  previously  mentioned,  the  satisfaction  of  certain  liveness  conditions 
depends  on  fair  computation.  We  therefore  require  only  that  every  fair  behavior  of  O, 
be  a  fair  behavior  of  0<_ j.  That  is,  0*  is  said  to  satisfy  Oi-i  if  fbeh(Oi)  C  fbeh(Ot_i). 
We  also  require  that  0 ,•  and  0,_i  have  the  same  external  action  signature. 

Notice,  however,  that  this  notion  of  correctness  is  not  completely  satisfactory.  In 
particular,  a  schedule  module  O,  with  no  schedules  trivially  satisfies  every  problem  Ot_i 
(with  the  same  external  action  signature).  Furthermore,  since  the  schedules  of  Oi  are 
allowed  to  be  arbitrary  sequences  of  actions,  it  is  conceivable  that  they  may  encode 
information  allowing  the  solution  of  undecidable  problems,  and  hence  not  be  behaviors 
of  an  implementable  system.  In  an  attempt  to  avoid  such  anomalies,  we  say  that  the 
object  0,_i  is  implementable  if  there  is  an  automaton  satisfying  0,_ j.  The  object  0,_!  is 
implementable  in  the  sense  that  there  is  a  system  satisfying  every  correctness  condition 
satisfied  by  0,_x.  Furthermore,  since  0,_i  is  satisfied  by  an  automaton,  and  since 
every  automaton  is  input-enabled,  the  object  Ot-_ i  must  describe  a  response  to  every 
possible  pattern  of  input.  That  is,  the  behavior  of  Oj_*  is  nontrivial.  We  say  that  0,_x 
solves  Oi  if  0<_  i  is  an  implementable  object  satisfying  0<.  In  the  context  of  constructing 
hierarchical  correctness  proofs,  such  a  proof  consists  of  a  sequence  Ox, . . . ,  0n  of  objects, 
and  the  verification  that  each  0,-  solves  0,_  t . 

Clearly,  the  notion  of  satisfaction  is  the  basis  of  each  of  these  definitions.  The 
remainder  of  this  section  concerns  techniques  for  verifying  that  one  object  satisfies 
another.  Two  properties  of  satisfaction  are  very  easy  to  see.  The  first  is  that  satisfaction 
is  transitive,  and  a  weak  congruence  with  respect  to  composition. 

Lemma  26:  Consider  the  objects  0,,  Pit  and  Qi,  for  i  G  I. 

1.  If  Oi  satisfies  Pi  and  Pi  satisfies  then  Oi  satisfies  Qi. 

2.  If  0,  satisfies  P,  for  every  i  G  /,  then  n«  satisfies  J]«  Pi  whenever  the  composi¬ 
tions  n.  0,  and  n.  Pi  &re  defined. 


Proof:  The  proof  of  the  first  part  is  immediate  from  the  definition  of  satisfaction. 
The  second  part  requires  some  proof.  As  a  result  of  Corollary  8,  the  external  action 
signature  of  fit  Oi  is  the  composition  of  the  external  action  signatures  of  the  0,  ,  and 
similarly  for  fit  P«-  Since  0,  and  Pi  have  the  same  external  action  signature  for  all 
i  G  /,  so  do  [j*  Oi  and  fl.  P<-  Since  fbeh(Oi)  C  fbeh(Pi)  for  all  »  G  I,  it  follows  by 
Lemma  20  that  /&eh(n,  Oi)  C  fbeh{Hi  Pi).  Therefore,  O*  satisfies  fl<  Pi-  □ 

A  second  property  of  satisfaction  is  its  invariance  under  action  renaming. 

Lemma  27:  Let  /  be  an  action  mapping  applicable  to  the  objects  0  and  P.  If  0 
satisfies  P,  then  f(0)  satisfies  /(P). 
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Proof:  Since  0  and  P  have  the  same  external  action  signature  and  since  /  is  injective, 
f(0)  and  /(P)  have  the  same  external  action  signature.  Using  Lemma  15  we  see  that 
fbeh(f{0))  C  fbeh(f{P)).  Thus,  /(0)  satisfies  /(P).  □ 

While  we  have  repeatedly  indicated  that  our  hierarchical  correctness  proofs  consist 
of  a  sequence  of  objects  Of, . . . ,  On  modeling  an  algorithm  at  different  levels  of  abstrac- 
tion,  our  proofs  typically  have  more  structure  than  this.  In  the  proof  of  Schonhage’s 
resource  arbiter  (in  the  next  chapter),  for  example,  we  actually  construct  for  each  level 
of  abstraction  an  automaton  A*  describing  the  algorithm  at  the  appropriate  level  of 
abstraction.  This  automaton  describes  as  much  of  the  algorithm  as  can  be  described 
by  its  static  nature.  In  particular,  the  automaton  A*  encodes  all  safety  conditions  re¬ 
quired.  If  liveness  conditions  are  required,  we  construct  an  execution  module  E,  of  A, 
with  those  executions  of  A,-  satisfying  the  desired  liveness  conditions.  The  objects  Oj 
referred  to  above  are  actually  the  execution  modules  E%.  We  note,  however,  that  the 
execution  module  En  at  the  lowest  level  of  abstraction  typically  consists  of  the  fair 
executions  of  An.  Thus,  at  the  lowest  level  of  abstraction  the  protocol  is  completely 
described  by  an  automaton,  and  we  could  use  the  object  An  in  place  of  the  execution 
module  En  in  the  correctness  proof.  Since  automata  and  execution  modules  are  the 
types  of  objects  most  frequently  used  in  correctness  proofs,  in  the  remainder  of  this 
section  we  give  techniques  for  proving  the  satisfaction  of  one  automaton  or  execution 
module  by  another. 

2.3.1  Automaton  Satisfaction 

We  now  describe  one  method  for  proving  that  an  automaton  A  satisfies  an  automa¬ 
ton  B.  This  method  makes  use  of  the  notion  of  a  possibilities  mapping,  a  corre¬ 
spondence  between  the  states  of  the  two  automata  that  can  be  used  to  prove  that  A 
satisfies  B. 

Suppose  A  and  B  are  automata  with  the  same  external  action  signature,  and  sup¬ 
pose  h  is  a  mapping  from  atatea{A)  to  the  power  set  of  atatea(B).  The  mapping  h  is 
said  to  be  a  poaaibilitita  mapping  from  A  to  B  if  the  following  conditions  hold: 

1.  For  every  start  state  a  of  A,  there  is  a  start  state  b  of  B  such  that  6  €  h(a). 

2.  For  every  reachable  state  a  of  A,  every  step  (a,  x,a')  of  A,  and  every  reachable 
state  6  €  h(a)  of  B : 

(a)  If  x  €  aeta(B),  then  there  is  a  step  (6,x,V)  of  B  such  that  V  €  h(o'). 

(b)  If  x  g  acta(B),  then  b  €  h(o'). 

If  a  is  a  state  of  A,  then  a  state  b  €  h(a )  of  B  is  referred  to  as  a  poaaibility  for  a. 
Informally,  6  is  an  abstract  state  corresponding  to  the  less  abstract  state  a.  The  fact 


that  h  map*  a  to  a  set  of  possibilities  allows  for  the  chance  that  many  abstract  state* 
may  correspond  to  the  single  concrete  state  a.  The  first  condition  of  a  possibilities 
mapping  says  that  every  start  state  of  A  has  as  one  of  its  possibilities  a  start  state 
of  B.  The  second  condition  says  that  steps  A  and  B  preserve  possibilities:  If  b  is  a 
possibility  for  a,  then  for  every  step  (a,x,a')  of  A  either  b  is  also  a  possibility  for  a', 
or  there  is  a  step  ( b ,  x,  b1)  of  B  with  the  property  that  V  is  a  possibility  for  a.  This 
definition  generalizes  the  definition  of  a  possibilities  mapping  used  in  the  context  of 
Event-State  Algebras  in  [Lyn83].  It  is  also  reminiscent  of  the  notion  of  bisimulation 
from  CCS  presented  in  [Mil80j.  Roughly  speaking,  a  possibilities  mapping  from  A 
to  B  is  a  mapping  from  the  states  of  A  to  the  states  of  B  with  the  property  that  if  a 
corresponds  to  6,  and  if  A  can  make  a  transition  via  the  action  x  from  a  to  o',  then  B 
can  make  a  transition  via  the  action  x  from  &  to  a  state  V  corresponding  to  o'.  Milner’s 
notion  of  bisimulation  is  essentially  a  pair  of  possibilities  mappings,  one  from  A  to  B 
and  another  from  B  to  A. 

We  now  show  how  to  use  a  possibilities  mapping  to  prove  that  A  satisfies  B.  Our 
first  step  is  to  show  how  such  a  mapping  relates  the  executions  of  A  to  the  executions 
of  B.  Given  two  finite  executions  z  and  y  of  A  and  B,  respectively,  we  say  that  y 
finitely  corresponds  to  x  under  h  if  sehed{y)  =  sehed(x)\B  and  the  final  state  of  y  is  a 
possibility  for  the  final  state  of  z.  In  general,  if  z  and  y  are  two  executions  of  A  and  £, 
we  say  that  y  corresponds  to  z  under  h  if  for  every  finite  prefix  z,  =  ao*iOi ...  a,  of  z 
there  is  a  finite  prefix  y,  of  y  finitely  corresponding  to  z,  under  h  such  that  y  is  the  limit 
of  the  y,.  Informally,  the  executions  z  and  y  model  the  same  computation  at  different 
levels  of  abstraction.  Our  next  result  shows  that  by  inductively  constructing  the  y,  it 
is  always  possible  to  construct  such  an  execution  y. 

Lemma  28:  Let  h  be  a  possibilities  mapping  from  A  to  B.  If  z  is  an  execution  of  A, 
then  there  is  an  execution  y  of  B  corresponding  to  z  under  h. 

Proof:  Let  z  =  ao*iOi  —  For  each  »  >  0,  let  x,  =  00*1*1  ...a*.  We  construct  the 
finitely  corresponding  y<  inductively,  and  take  y  to  be  the  limit  of  the  y,.  Since  ao  is 
a  start  state  of  A,  the  set  h(a 0)  must  contain  a  start  state  of  B,  and  hence  it  is  easy 
to  choose  an  execution  yo  finitely  corresponding  to  zo  under  h.  Suppose  y,_  1  finitely 
corresponds  to  under  h,  and  let  us  construct  y*.  First,  a*_i  is  a  reachable  state 
of  A,  and  (a,-i,Xi,Oi)  is  a  step  of  A.  Second,  the  final  state  b  of  y,_x  is  a  reachable  state 
of  B  in  h(a,_i).  If  x<  G  aets[B),  then  by  the  definition  of  h  there  is  a  state  V  in  h(a,) 
such  that  (b,*i,V)  is  a  step  of  B.  If  y,  =  yi-i*iV,  then  the  final  state  of  y<  is  in  h(a,) 
and  sched(xi)\B  =  sehed{yi).  If  x<  £  acts(B),  then  from  the  definition  of  h  we  see  that 
b  €  h(oi).  If  y,  =  jfc_x,  then  the  final  state  of  y,  is  in  h(a,)  and  sehed(xi))B  =  sched{yi). 
In  either  case,  y<  finitely  corresponds  to  z<  under  h.  □ 

Since  each  pair  of  prefixes  z,  and  y,  satisfies  the  condition  sched{xi)\B  =  sehed( yt), 
it  is  easy  to  see  that  the  executions  z  and  y  do  so  as  well. 
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Lemma  30:  Let  h  be  a  possibilities  mapping  from  A  to  B.  If  the  execution  y  of  B 
corresponds  to  the  execution  x  of  A  under  h,  then  ached  {z)\B  =  ached  (y). 

Proof:  Suppose  that  ached  (x)  |  B  ^  ached  (y) .  Since  x  and  y  are  the  limits  of  finitely  cor¬ 
responding  prefixes  x,  and  y,,  respectively,  there  must  be  an  i  such  that  ached  (zi)\B  / 
•eked (y<).  However,  since  y,  finitely  corresponds  to  z{  under  h,  this  is  impossible.  Thus, 
ached(z)\B  =  tched  (y).  □ 

Having  established  a  correspondence  between  the  executions  of  A  and  B,  we  show 
with  the  following  result  how  this  correspondence  can  be  used  to  show  that  A  satisfies  B. 
We  say  that  one  equivalence  relation  is  a  contained  in  a  second  if  every  class  of  the  first 
is  contained  in  a  class  of  the  second. 

Lemma  30:  Let  A  and  B  be  automata  such  that  part(B)  is  contained  in  part  {A). 
Let  h  be  a  possibilities  mapping  from  A  to  B.  Suppose  the  following  condition  holds 
for  all  reachable  states  a  of  A  and  for  all  classes  C  and  D  of  part  (A)  and  part(B), 
respectively,  such  that  C  D  D:  If  an  action  of  D  is  enabled  from  a  reachable  state 
of  h(a),  then  an  action  of  D  is  enabled  from  a  and  no  action  of  C  —  D  is  enabled 
from  a. 

Proof:  Since  h  is  a  possibilities  mapping  from  A  to  B,  both  automata  have  the  same 
external  action  signature.  We  need  only  show  that  fbeh{A)  C  fbeh(B).  Let  x  be  a  fair 
execution  of  A ,  and  let  y  be  an  execution  of  B  corresponding  to  x  under  h.  We  claim 
that  y  is  a  fair  execution  of  B.  Since  tcked(z)\B  =  eched(y)  and  ext(A)  =  ezt(B),  we 
will  have  that  ached(z)\ezt(A)  =  ached  (y)\czt(B),  and  hence  that  fbeh(A)  C  fbeh(B). 
For  each  i  >  0,  let  x<  be  the  prefix  Oo^a* . . .  a,  of  x,  and  let  y,  be  the  prefix  of  y  finitely 
corresponding  to  x,  under  h. 

Suppose  y  is  finite.  Suppose  there  is  a  class  D  of  B  such  that  an  action  of  D  is 
enabled  from  the  final  state  of  y.  Since  y  is  finite,  y  =  y,  for  some  s'.  Since  an  action 
of  D  is  enabled  in  B  from  a  reachable  state  in  h(a;)  for  all  j  >  i  (namely,  the  final  state 
of  y),  for  all  j >  i  an  action  from  D  is  enabled  in  A  from  a,,  and  no  action  from  C  —  D 
is  enabled  in  A  from  a,.  If  x  is  finite,  then  an  action  of  C  is  enabled  from  the  final  state 
of  x.  If  x  is  infinite,  then  from  every  state  a}  ( j  >  i)  an  action  of  C  is  enabled  and  yet 
no  action  of  C  is  performed  (or  it  would  appear  in  y).  In  either  case,  this  contradicts 
our  initial  assumption  th?t  x  is  a  fair  execution,  so  y  must  be  a  fair  execution  of  B. 

Conversely,  suppose  y  is  infinite.  Suppose  there  is  a  class  D  such  that  an  action 
from  D  is  enabled  from  all  but  finitely  many  states  appearing  in  y.  It  follows  that  for 
all  but  finitely  many  t,  an  action  of  D  is  enabled  from  a  reachable  state  of  h(o,)  in  B. 
Therefore,  for  all  but  finitely  many  t,  there  is  an  action  of  D  enabled  from  a,  in  A,  and 
no  action  from  C  —  D  enabled  from  a,-.  Since  x  is  a  fair  execution  of  A,  there  must  be 
infinitely  many  actions  from  D  appearing  in  x,  and  hence  in  y.  Therefore,  y  must  be 
a  fair  execution  of  B.  □ 


We  remark  that  the  requirement  that  part(B)  be  contained  in  part  (A)  is  not  un¬ 
reasonable  when  B  models  an  algorithm  at  a  higher  level  of  abstraction  than  A.  The 
restriction  implies  that  the  actions  of  B  are  a  subset  of  the  actions  of  A.  Since  A  and  B 
have  the  same  external  action  signature  (A  is  a  possibilities  mapping  from  A  to  B), 
this  implies  that  some  low-level  internal  actions  of  A  may  not  be  internal  actions  of  B. 
Even  when  this  requirement  is  not  met,  however,  the  correspondence  between  states 
established  by  a  possibilities  mapping  is  still  a  useful  correspondence  when  reasoning 
about  the  behavior  of  the  automaton.  For  example,  in  Section  2.3.2  we  will  see  how 
this  correspondence  can  be  used  to  verify  that  one  execution  module  (of  an  automaton) 
satisfies  a  second. 

Our  final  result  concerning  possibilities  mappings  shows  that  possibilities  mappings 
have  a  very  nice  local  behavior:  Given  two  automata  A  =  fit  A«  and  B  =  n«  B*  together 
with  a  possibilities  mapping  from  A«  to  B,  for  every  i,  these  possibilities  mappings 
induce  a  possibilities  mapping  from  A  to  B. 

Lemma  31:  Suppose  for  all »  €  /  that  hi  is  a  possibilities  mapping  from  A*  to  B,-,  and 
that  acts(Ai)  D  aets(Bt).  Let  A  =  I"I«  A,  and  B  =  IL  -8,.  If  h  is  the  mapping  from 
states  (A)  to  the  power  set  of  states(B)  defined  by  h(a)  —  {b  :  6|B*  G  h,(a|A,)},  then  h 
is  a  possibilities  mapping  from  A  to  B. 

Proof:  As  a  result  of  Corollary  8,  the  external  action  signature  of  a  composition  is  the 
composition  of  the  external  action  signatures  of  its  components.  Since  the  Ai  and  B, 
have  the  same  external  action  signatures,  A  and  B  must  also  have  the  same  external 
action  signature.  Thus,  we  need  only  check  that  conditions  1  and  2  of  a  possibilities 
mapping  hold.  For  the  first  condition,  for  every  Oi  G  start(Ai)  there  is  a  6,  G  states{Bi) 
such  that  fc,  G  h,(o,).  Thus,  for  every  a  G  start  (A)  there  is  a  b  G  start  (B)  such  that 
6  G  h(a).  For  the  second  condition,  suppose  that  a  is  a  reachable  state  of  A,  (a,  x,a') 
is  a  step  of  A,  and  b  G  h[a)  is  a  reachable  state  of  B.  Let  a<  =  a|A«,  a'  =  a'|A«,  and 
bi  =  b\Bi  for  every  *  G  /.  Notice  that,  since  a  and  b  are  reachable  states  of  A  and  B, 
Oi  and  bi  must  be  reachable  states  of  Ai  and  B<. 

Suppose  that  ir  G  aets(B).  We  must  construct  a  step  (6, x,V)  of  B  with  V  G  A(a'). 
Suppose  x  G  acts(B,).  Then  x  G  acts(Ai),  so  (a,,x,a!)  must  be  a  step  of  A,.  Since  A, 
is  a  possibilities  mapping  from  Ai  to  B<,  there  is  a  step  (6<,x,fc{)  of  B<  with  6J  G  MaJ). 
Suppose  x  g  acts(Bi).  If  x  G  aeis(A,),  then  (o,-,x,oJ)  is  a  step  of  A*,  and  bi  G  A,  (a') 
by  definition  of  A,.  If  x  acts(Ai),  then  a<  =  aj,  and  so  6,  G  h<(a<)  =  A,(a').  In  either 
case,  let  =  V  It  follows  that  (fc,,x,6J)  is  a  step  of  B<  if  x  G  aets(Bi),  and  that  bi  = 
if  x  £  aets(B, ).  If  b  is  the  state  of  B  such  that  =  V\Bi  for  all  *,  then  (6,  x,V)  is  a 
step  of  B.  Furthermore,  V  G  A(o')  as  desired. 

Suppose  that  x  £  aets(B).  Then  x  ^  aets(Bi)  for  all  *.  As  above,  bi  G  A*(oJ)  for 
all  i,  and  so  6  G  h(a')  as  desired.  Thus,  h  is  a  possibilities  mapping  from  A  to  B.  □ 
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2.3.2  Execution  Module  Satisfaction 


Ai  previously  mentioned,  when  constructing  the  correctness  proof  of  an  algorithm,  we 
first  construct  automata  Ax, ....  A*  describing  the  algorithm  at  several  levels  of  ab¬ 
straction.  If  the  algorithm  is  required  to  satisfy  certain  liveness  conditions,  we  also 
construct  execution  modules  Ei  of  A,  describing  these  liveness  conditions.  The  remain¬ 
der  of  the  correctness  proof  consists  of  proving  that  each  E,  satisfies  E,-i.  We  now 
show  how  possibilities  mappings  can  be  used  to  prove  that  certain  execution  modules 
satisfy  other  execution  modules. 

We  remark  that  one  correctness  condition  common  to  many  system  specifications 
is  a  condition  of  the  form  “if  condition  P  holds,  then  eventually  condition  Q  holds.” 
Lamport  denotes  this  temporal  logic  statement  □(/*  D  O Q)  by  P  <5  in  [Lam77], 
read  UP  leads  to  Q.”  Given  an  automaton  A,  a  set  of  states  S ,  and  a  set  of  actions  T,  a 
simple  correctness  condition  common  to  specifications  in  our  model  (see  Chapter  3,  for 
instance)  is  the  condition  “if  the  current  state  of  A  is  contained  in  5,  then  eventually 
an  action  of  T  will  be  performed.”  With  Lamport's  notation  in  mind,  we  denote  this 
condition  by  S  *-*  T.1  Given  two  execution  modules  E  and  F  satisfying  a  collection  of 
such  conditions,  we  now  show  how  a  possibilities  mapping  can  be  used  to  show  that  E 
satisfies  F.  We  begin  with  a  result  relating  individual  executions. 

Lemma  32:  Let  h  be  a  possibilities  mapping  from  A  to  B.  Let  x  be  an  execution 
of  A,  and  let  y  be  an  execution  of  B  corresponding  to  z  under  h. 

1.  If  y  satisfies  U  «-»  V,  and  if  h(S)  C  U  and  T  D  V,  then  x  satisfies  S  *-►  T. 

2.  If  x  satisfies  S  «— »  2\  and  if  5  D  h~l(U)  and  T  C  V,  then  y  satisfies  U  «-  V. 

Proof:  Let  x  =  oo^xOx . . and  let  y  =  boPibi  —  For  each  »  G  /,  let  x*  =  ao*iax . . .  a,, 
and  let  y«  be  the  prefix  of  y  finitely  corresponding  to  x<  under  h. 

Suppose  y  satisfies  U  <-*  V,  and  let  us  show  that  z  satisfies  S  *-*  T.  It  is  enough 
to  show  that  if  a»  €  S,  then  G  T  for  some  t>  k.  Since  y*  finitely  corresponds  to  x* 
under  h,  we  have  y*  =  6xPx&i .  •  .  bm  with  bm  G  f°r  m.  Since  a*  G  S  and 

h(S)  C  U,  we  have  bm  G  U.  Since  y  satisfies  U  *— ►  V,  we  have  <pn  G  V  for  some  n  >  m. 
Since  VC  T,  for  some  t  >  k  we  have  ached{zt)\B  =  $ched(yn)  where  tehed{xi)\B  and 
ached (yn)  both  end  with  <pn.  Therefore,  for  some  l  >  k  we  have  xt  =  <pm  G  T,  as 
desired. 

Conversely,  suppose  x  satisfies  5  «-♦  T,  and  let  us  show  that  U  *-»  V  is  satisfied  by  y. 
It  is  enough  to  show  that  if  6*  G  l/,  then  pjG  V  for  some  t  >  k.  Since  ym  =  bo<pi . . .  fc* 

‘The  etstement  S  t—  T  u  eMentUUy  *  atstement  in  temporal  lofic,  aa  ia  0(P  O  OQ).  The  fact  that 
execntiona  are  aeqnencea  of  atatea  and  actiona,  instead  of  aimply  infinite  aeqnencea  of  atatea,  mean*  the 
atandard  model  for  temporal  logic  moat  be  alightly  modified  if  the  condition  S  *— < *  T  ia  to  be  expreaaed 
in  temporal  logic. 
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finitely  corresponds  to  xm  =  ao*i . . .  a.  for  some  m,  we  hive  6*  €  h(a«,).  Since  €  U 
and  h~l(U)  C  S,  we  have  am  €  S.  Since  z  satisfies  5  «-*  T,  for  some  n  >  m  we  have 
*m  €  T.  Since  »eh*d(zn)\B  =  •ched(yn)  and  T  C  V  C  actt(B),  we  see  that  the  final 
action  of  y»  is  tr„.  If  y*  =  6©  ■  •  •  then  <Pt  =  *n  €  V  for  some  t  >  k  as  desired.  □ 

With  this  result,  we  are  now  able  to  give  the  following  sufficient  condition  for  the 
satisfaction  of  one  execution  module  by  another. 

Lemma  S3:  Let  h  be  a  possibilities  mapping  from  A  to  B.  Let  E  be  the  execution 
module  of  A  with  the  executions  of  A  satisfying  the  conditions  S<  ►  T,  for  every 
i  €  /,  and  let  F  be  the  execution  module  of  B  with  the  executions  of  B  satisfying  the 
conditions  U,  «—►  Vt  for  every  i  €  /.  If  for  every  »  €  /  we  have  that  5,  D  h~l(Ui)  and 
T,  C  Vt,  then  E  satisfies  F. 

Proof:  Since  h  is  a  possibilities  mapping  from  A  to  B,  these  automata  (and  hence 
the  execution  modules  E  and  F)  have  the  same  external  action  signature.  Let  z  be  an 
execution  of  E,  and  let  y  be  an  execution  of  B  corresponding  to  z  under  h.  Since  z 
satisfies  5,  ■— ►  T,  for  every  t,  Lemma  32  implies  that  y  satisfies  Ui  t-»  V,  for  every  t.  It 
follows  that  y  is  an  execution  of  F.  Therefore,  fbth{E)  C  fbch(F),  and  E  satisfies  F. 

□ 

We  conclude  with  a  simple  result  relating  conditions  of  the  form  S  •— *  T  satisfied 
by  executions  of  a  composition  >(  automata  to  conditions  of  the  form  S'  t~*  T*  satisfied 
by  executions  of  an  individual  component. 

Lemma  34:  Let  A  =  Hid*z{T\i  ^)-  Let  S  C  stot«s(4),  and  let  S,  =  {«|4,  :  s  €  5). 
If  z  is  an  execution  of  A,  then  z  satisfies  the  5  *— ►  T  iff  zj Aj  satisfies  S,  *— *  T. 


Chapter  3 
An  Example 


As  an  example  of  the  hierarchical  organisation  of  correctness  proofs  proposed  in  the 
preceding  chapter,  in  this  chapter  we  prove  the  correctness  of  Schonh age’s  distributed 
resource  allocation  algorithm  described  in  the  introduction.  The  problem  is  to  design 
an  arbiter  allocating  a  resource  among  a  collection  of  users  that  guarantees  the  mutual 
exelution  condition  that  at  most  one  user  is  using  the  resource  at  any  given  time; 
and  the  no  lockout  condition  that  if  users  holding  the  resource  eventually  return  the 
resource,  then  the  arbiter  will  eventually  satisfy  every  requesting  user.  The  distributed 
system  in  which  this  arbiter  is  to  be  used  is  completely  asynchronous:  processor  speeds 
may  be  independent;  messages  may  take  an  arbitrary,  finite  amount  of  time  to  be 
delivered;  and  messages  may  be  delivered  in  any  order. 

The  arbiter  itself  is  described  in  parallel  with  the  proof  of  its  correctness.  We  begin 
with  a  high-level  model  serving  as  a  simple  specification  of  the  problem  the  arbiter  is 
to  solve.  We  then  give  a  graph- theoretic  description  of  the  algorithm’s  global  behavior. 
Finally,  the  arbiter  is  distributed  and  described  in  terms  of  a  low-level  protocol  to  be 
followed  by  the  processors  comprising  the  arbiter.  We  show  that  this  low-level  model 
solves  the  high-level  problem  specification,  and  hence  that  the  given  protocol  is  a  correct 
solution  to  the  arbiter’s  problem  specification. 


3.1  The  Automaton  A\ 

Our  high-level  model  of  the  arbiter,  the  automaton  A\t  is  a  very  simple  specification 
of  the  arbiter’s  correctness  conditions.  We  refer  to  the  arbiter  itself  as  a,  and  to  the 
users  of  the  arbiter  as  U|, . . . ,  t*n.1 

1  Is  general,  we  will  denote  entities  associated  with  the  arbiter  by  the  letter  a,  and  entities  associated 
with  the  oners  by  letter  u.  Letters  near  the  end  of  the  alphabet  each  as  v  and  w  will  be  need  to  denote 
entities  associated  with  either  the  arbiter  or  the  osers. 
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Input  Action*: 
rtfusst(u) 

«CrU: 

requester*  *—  rtfwiUn  u  {u} 

retsrs(u) 

effects: 

if  holder  =  u  then 
holder  «—  a 

Output  Actions: 
fro*t{u) 

proconditions: 

u  €  requester* 
holder  =  a 
offsets: 

requesters  «—  requester*  -  {u} 
holder  «—  u 

Figure  3.1:  The  actions  of  A\. 

3.1.1  The  States  of  Ai 

A  state  of  A\  consists  of  a  set  requesters  C  {ult . . . ,  u«}  of  requesting  processes,  together 
with  a  value  holder  e  {ult . . . ,  u„,  a}  indicating  the  entity  currently  holding  the  resource 
(either  a  user  or  the  arbiter  itself).  The  start  state  of  Ai  is  the  state  in  which  the  set 
requesters  of  requesting  users  is  empty,  and  the  initial  holder  is  the  arbiter  a  itself.  We 
note  that  all  states  of  A\  are  reachable,  as  a  'ill  become  clear  when  the  actions  of  A\ 
have  been  introduced. 

3.1.2  The  Actions  of  A\ 

The  actions  of  At  are  given  in  Figure  3.1.  We  specify  the  transition  relation  of  an 
automaton  by  giving  for  each  action  a  list  of  preconditions  and  effects.  An  action  is 
enabled  from  any  state  s  satisfying  the  action’s  preconditions,  and  the  action  takes  s 
to  the  state  t  if  t  can  be  obtained  by  modifying  s  as  indicated  by  the  action’s  effects. 
Since  input  actions  are  enabled  from  every  state,  we  omit  the  preconditions  of  input 
actions. 

The  input  actions  of  A\  are  of  the  form  request  (u)  and  return(u),  where  u  is  a  user. 
The  action  request  (u)  simply  places  the  user  u  in  the  set  requesters  of  requesting  users. 
Since  automata  are  input-enabled,  a  user  is  able  to  request  the  resource  at  any  time, 
even  when  it  is  currently  holding  the  resource.  The  effect  of  a  user’s  requesting  the 
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resource  while  holding  the  resource  is  thst  the  request  is  recorded  for  later  use  (later 
servicing  of  the  user).  The  action  return (u)  returns  the  resource  to  the  arbiter  by 
making  the  arbiter  the  new  holder  of  the  resource.  Notice  that  if  a  (faulty)  user  tries 
to  return  the  resource  when  it  does  not  actually  hold  it,  the  arbiter  simply  ignores  the 
“return.”  The  automaton  Ai  has  no  internal  actions.  The  output  actions  of  Ai  are  of 
the  form  grant  ( u),  where  u  is  again  a  user.  The  arbiter  grants  the  resource  to  u  with 
the  action  grant  (u),  which  removes  u  from  the  set  of  requesting  users  and  makes  u 
the  new  holder  of  the  resource.  Notice  that  the  arbiter  grants  the  resource  only  when 
the  arbiter  actually  holds  the  resource.  Consequently,  at  most  one  user  is  using  the 
resource  at  any  time. 

3.1.3  The  Execution  Module  E\ 

While  the  executions  of  Ai  satisfy  the  mutual  exclusion  condition  that  at  most  one  user 
is  using  the  resource  at  any  given  time,  we  must  still  ensure  the  no  lockout  condition 
is  satisfied  by  the  arbiter:  If  users  using  the  resource  eventually  return  the  resource  to 
the  arbiter,  then  the  arbiter  eventually  satisfies  every  request  for  the  resource.  Let  u 
be  a  user  node,  and  let  us  define  the  following  sets  of  states  and  actions.2 

RtnRe$[( u)  =  {a  G  state*(Ai)  :  holder  =  u  in  «} 

RtnRes“(u)  =  { return  (u)} 

GrRe*\{ u)  =  (a  €  »tate*(Ai)  :  u  G  requesters  in  s) 

GrRe«“(u)  =  {grant  (u)} 

The  condition 

RtnResi  =  /\  RtnRcs[(u)  *-►  RtnRe$1(u) 

U 

says  that  any  user  holding  the  resource  will  eventually  return  the  resource  to  the  arbiter. 
The  condition 

GrReti  =  f\  Gr/2esJ(u)  GrRcs\(u) 

U 

says  that  any  user  requesting  the  resource  will  eventually  be  granted  the  resource.  The 
correctness  condition 

Ci  =  RtnRcti  D  GrRts \ 

3  We  will  be  defining  eeverai  correctness  conditions  for  each  of  the  models  we  stndy.  We  will  subscript 
these  conditions  to  indicate  the  level  of  abstraction  with  which  they  are  associated.  Furthermore,  the 
sets  of  states  and  actions  used  to  construct  these  conditions  will  be  superscripted  with  the  letters  s  or  a, 
respectively. 


Ui 


Figure  3.2:  One  state  of  the  arbiter  modeled  by  Aj. 

says  that  if  users  holding  the  resource  always  return  the  resource,  then  users  requesting 
the  resource  will  always  be  granted  the  resource.  This  is  precisely  the  no  lockout 
condition  we  require  the  arbiter  to  satisfy.  We  denote  by  Ex  the  execution  module 
of  Ax  with  the  executions  of  Ax  satisfying  the  condition  Cx.  The  execution  module  £, 
serves  as  the  specification  of  the  arbiter. 

3.2  The  Automaton  Ai 

Our  next  model  reveals  the  distributed  structure  of  the  arbiter,  but  still  at  a  high  level 
of  abstraction,  a  level  at  which  one  might  describe  the  algorithm  at  the  blackboard.  In 
this  model,  illustrated  in  Figure  3.2,  the  arbiter  and  its  environment  are  modeled  by 
a  connected,  acyclic  graph  G.  The  leaves  of  G  are  user  nodes  representing  the  users, 
labeled  ut,...  ,u„.  The  arbiter  itself  consists  of  the  remaining  arbiter  nodes ,  labeled 
oi, . . .  ,0m.  The  (directed)  edge  of  G  from  the  node  v  to  w  is  denoted  by  (v,w).  An 
edge  (v,  w)  is  said  to  point  toward  a  node  x  if  (v,  w)  is  an  edge  in  the  path  from  v  to  z. 
Arrows  are  placed  on  edges  of  the  graph  to  indicate  either  a  request  for  the  resource 
or  the  granting  of  the  resource.  In  general,  the  resource  is  considered  to  be  held  by  a 
node  at  the  head  of  a  grant  arrow.  Such  a  node  is  called  a  root  of  the  graph.  A  user  u 
requests  the  resource  by  placing  a  request  arrow  on  the  edge  (u,a)  from  itself  to  the 
adjacent  arbiter  node  a.  The  arbiter  grants  the  resource  to  u  by  removing  this  arrow 
and  placing  a  grant  arrow  on  ( o,  u ).  The  user  then  returns  the  resource  by  moving  the 
grant  arrow  from  the  edge  (a,  u)  to  the  edge  (u,a).  The  arbiter  itself,  however,  is  an 


acyclic  graph  of  arbiter  nodes.  When  the  head  of  a  request  arrow  is  placed  at  an  arbiter 
node  a,  the  arbiter  node’s  response  depends  on  whether  it  is  holding  the  resource.  If 
the  arbiter  node  a  holds  the  resource,  then  it  must  be  at  the  head  of  a  grant  arrow, 
and  so  there  must  be  a  grant  arrow  on  some  edge  (v,a).  The  arbiter  selects  the  first 
node  w  in  some  fixed  ordering  of  its  adjacent  nodes  having  a  request  arrow  on  (w,a). 
The  arbiter  then  grants  the  resource  to  this  node  by  removing  the  request  arrow  and 
moving  the  grant  arrow  to  the  edge  (a,  w).  In  this  case  we  say  that  the  resource  has 
been  forwarded  by  a  to  w.  If  the  arbiter  node  a  does  not  hold  the  resource,  then  the 
arbiter  forwards  the  request  in  the  direction  of  a  node  holding  the  resource  by  placing  a 
request  on  the  edge  pointing  toward  a  root.  The  work  in  this  section  holds  for  arbitrary 
connected,  acyclic  graphs.  When  we  consider  the  model  As  in  the  following  section, 
however,  we  will  restrict  our  attention  to  graphs  with  a  particular  structure. 

3.2.1  The  States  of  A* 

In  order  to  refer  conveniently  to  the  arrows  on  am  edge  of  the  graph,  we  associate  with 
each  edge  (v,w)  an  arrow  set,  arrows  (v,w),  containing  all  of  the  arrows  on  the  edge 
{v,w).  A  state  of  Aj  therefore  consists  of  one  arrow  set,  arrows (v, w),  for  every  edge 
{ v ,  w)  of  the  graph  G.  The  start  states  of  Ax  are  taken  from  the  set  of  states  in  which  a 
single  arrow  set  arrows  (v,  a)  contains  only  a  grant  arrow,  and  all  other  arrow  sets  are 
empty,  where  a  is  an  arbiter  node  of  the  graph  G.  In  such  a  state,  the  arbiter  holds 
the  resource  and  no  requests  for  the  resource  are  pending.  We  will  soon  restrict  our 
attention  to  a  particular  set  of  such  start  states  in  the  next  section,  but  the  work  of 
this  section  is  independent  of  the  particular  set  chosen.  We  note  that  some  states  of  Ax 
are  unreachable.  For  technical  convenience,  we  remove  these  states  from  Ax  so  that  all 
states  of  Ax  are  reachable. 

3.2.2  The  Actions  of  Ai 

Fix  for  each  node  of  G  an  (arbitrary)  ordering  of  its  adjacent  nodes.  Let  (v,w)  denote 
the  set  of  nodes  properly  between  the  nodes  v  and  w  in  this  ordering,  and  let  (v,w] 
denote  the  set  nodes  properly  between  v  and  w  together  with  the  node  w.  The  actions 
of  Ax  are  given  in  Figure  3.3.  The  input  actions  are  of  the  form  request  (u,  o)  and 
grant  (u,  a),  and  the  output  actions  are  of  the  form  grant  (a,  u),  where  u  is  a  user  node 
and  a  is  an  adjacent  arbiter  node.  The  internal  actions  are  of  the  form  request  (a,  u) 
where  u  is  a  user  node  and  a  is  an  adjacent  arbiter  node;  and  of  the  form  request  (a,  a') 
and  grant  (a,  a')  where  a  and  a'  are  adjacent  arbiter  nodes.  As  in  the  previous  model, 
users  may  request  or  grant  the  ticket  at  any  time,  but  grants  by  users  not  actually 
holding  the  ticket  are  effectively  ignored.  Note  we  have  added  internal  actions  with 
which  the  arbiter  may  request  that  the  user  return  the  resource.  The  arbiter  had  no 
such  ability  in  the  previous  model.  These  actions  have  been  added  for  the  sake  of 


Input  Action*: 

request(u,  a) 
effect*: 

arrow«(u,  a)  «—  srrows(u,  a)  U  {  request} 

front(u,  a) 
effects: 

if  front  €  arrows(a,  u)  then 

arrow* (a,  u)  «—  arrowo(a,u)  -  {refwoot} 
arrowo(a,u)  *—  o rrows(a,  u)  —  {front} 
arrows{ u,  a)  *—  arrow«(u,  a)  U  {front} 

Internal  and  Output  Actions: 
request(a,  v) 

preconditions: 

request  €  errows{w,  a)  for  some  w 
(a,  v)  points  toward  a  root 
request  g  mrrows(a,  v) 
effects: 

arrows(a,  v)  «—  arrows{a,  v)  U  {request} 

grant(a,  v) 

preconditions: 

ref  nest  €  or  row«(v,  a) 
front  €  o rrows(w,a)  for  some  w 
request  &  a rrovs(y,  a)  for  y  €  (w,  v) 
effects: 

*rrows(v,a)  *—  errows(v,  a)  -  {refnest} 
srrows(w,a)  *—  arrows(w,  a)  -  {front} 
orroto«(a,  v)  «—  arrows(a,  v)  U  {front} 


Figure  3.3:  The  actions  of  A). 


symmetry.  Having  been  added  as  internal  actions,  they  have  no  effect  on  the  arbiter’s 
interface  with  its  users. 

The  next  few  results  state  certain  invariants  that  hold  during  executions  of  A,.  The 
first  guarantees  that  every  state  contains  at  most  one  root,  and  hence  that  at  most  one 
user  is  using  the  resource  at  any  time. 

Lemma  35:  If  s  is  a  state  of  At,  there  is  exactly  one  root  in  s. 

Proof:  In  every  start  states  of  Aj,  precisely  one  arrow  set  contains  a  grant  arrow. 
Furthermore,  every  action  that  adds  a  grant  arrow  to  an  arrow  set  also  removes  a 
grant  arrow  from  an  arrow  set.  The  result  follows  by  a  simple  inductive  argument, 
since  all  states  of  At  are  reachable.  □ 

The  second  invariant  states  that  every  request  arrow  placed  on  the  graph  by  the 
arbiter  points  toward  the  root  of  the  graph.  In  other  words,  the  arbiter  correctly 
forwards  requests  in  the  direction  of  the  resource. 

Lemma  36:  Let  s  be  a  state  of  Aj,  and  let  a  be  an  arbiter  node  of  G.  If  arrows  (a,  v) 
contains  a  request  arrow,  then  (a,  v)  points  toward  the  root  of  G. 

Proof:  No  arrow  set  of  any  start  state  contains  a  request  arrow,  so  the  start  states  of  A* 
certainly  satisfy  the  hypothesis.  Suppose  s  is  a  state  of  Aj  satisfying  the  hypothesis, 
and  suppose  that  s  t  is  a  step  of  A).  We  claim  that  t  satisf  es  the  hypothesis  as  well. 
Suppose  x  is  of  the  form  request  (z,y).  Notice  that  x  does  not  modify  the  position  of 
the  grant  arrow,  and  that  x  adds  a  request  arrow  to  arrows  (o,  v)  only  if  (o,  v)  points 
toward  the  root  in  s,  and  hence  in  t.  It  follows  that  t  must  satisfy  the  hypothesis. 
Suppose  x  =  grartt(v,a).  In  this  case,  x  removes  any  request  arrow  from  arrow*  (a,  v), 
and  so  t  must  satisfy  the  hypothesis.  Finally,  suppose  x  =  grant (x,y)  /  grant  (v,  a). 
Since  x  does  not  add  or  remove  a  request  arrow  from  arrows  (a,  t/),  if  the  set  arrows  (a,  v) 
contains  a  request  arrow  in  t,  the  same  is  true  in  s.  The  fact  that  x  is  enabled  from  s 
implies  that  z  is  the  root  in  s.  The  hypothesis  implies  that  the  edge  (a,  v)  must  point 
toward  the  root  z  in  s.  Since  x  forwards  the  resource  from  z  to  y  (and  since  y  /  a)  the 
edge  ( a,v )  must  point  toward  the  root  y  in  t.  Therefore,  t  must  satisfy  the  hypothesis. 
The  lemma  now  follows  by  a  simple  inductive  argument,  since  all  states  of  Aj  are 
reachable.  □ 

3.2.3  The  Execution  Module  E2 

To  ensure  that  the  arbiter  satisfies  all  user  requests,  it  is  obviously  important  that  the 
internal  arbiter  nodes  forward  all  requests  in  the  direction  of  the  root,  and  that  arbiter 
nodes  holding  the  resource  eventually  grant  the  resource  to  adjacent  requesting  nodes. 


Let  a  be  an  arbiter  node  adjacent  to  nodes  v  and  «/,  and  let  ua  define  the  following  sets 
of  states  and  actions. 

FwdJUqfc(a,v)  —  {s  €  atatcs{Ai)  :  request  €  arrows (w, a)  for  some  w, 

(a,v)  points  toward  the  root,  and 
request  &  arrows  (a,  v)  in  a} 

FwdReq\(a,v)  =  {front  (v,  a),  request  (a,  v)} 

FwdGr\[a,v,w)  =  {s  €  states(A%)  :  request  €  arrows (t>, a)  and 

grant  €  arrows  (tv,  a)  in  «} 

FwdGr}(a,v,w)  =  (frant(o,y)  :  y  G  (u;,v]} 

The  first  arbiter  correctness  condition 

FwdReqt  =  FwdReq\(a,  v)  <-»  FwdRcq\(a ,  v ), 

illustrated  at  the  top  of  Figure  3.4,  states  that  if  an  arbiter  node  a  is  at  the  head  of 
a  request  arrow  and  has  not  forwarded  the  request  in  the  direction  of  the  root,  then 
either  a  becomes  the  root  (possibly  because  v  is  a  user  node,  and  v  has  placed  a  front 
arrow  on  (v,a)),  or  a  eventually  forwards  the  request  in  the  direction  of  the  root.  The 
second  arbiter  correctness  condition 

FwdGrt  =  ^  FwdGr\[a,v,w)  «— ►  /WGr£(a,v, w), 

illustrated  at  the  bottom  of  Figure  3.4,  states  that  if  an  arbiter  node  aba  root  at 
the  head  of  a  request  arrow,  then  it  eventually  forwards  the  resource  to  an  adjacent 
requesting  node.  The  correctness  condition 

C|  =  FwdReqt  A  FwdGr 3 

ensures  that  arbiter  nodes  always  forward  requests  in  the  direction  of  the  root;  and 
that  arbiter  nodes  holding  the  resource  always  grant  it  to  adjacent  requesting  nodes. 
We  let  Ei  be  the  execution  module  of  Ai  with  the  executions  of  At  satisfying  the 
condition  Cj. 

While  Lemma  35  states  that  at  most  one  user  b  using  the  resource  at  any  given 
time,  and  while  condition  Cj  ensures  that  arbiter  nodes  holding  the  resource  always 
grant  the  resource  to  requesting  nodes,  we  have  not  yet  shown  that  the  arbiter  always 
satbfies  user  requests.  As  before,  thb  requires  cooperation  on  the  part  of  the  users. 
Let  u  be  a  user  node  adjacent  to  the  arbiter  node  a,  and  let  us  define  the  following  sets 
of  states  and  actions. 

RtnRes\{ u)  =  (a  G  atatee(Aj)  :  grant  €  orrowa(a,u)  in  a) 


a 


a 


rtq%€*t 


The  correctness  condition  FwdRtqt. 


Figure  3.4:  Arbiter  correctness  conditions. 


RtnRc*Z(u)  =  {grant  (u,  a)} 


GrRes^(u)  —  {«  6  states(Ai)  :  request  €  arrow*  (u,  a)  in  «} 

GrRes%(  u)  =  {  grant  (a,  u)} 

The  condition 

RtnReSi  =  f\RtnRcs^( u)  «-*•  RtnRes\(u) 

U 

says  user  nodes  holding  the  resource  always  return  the  resource,  and  the  condition 

GrResi  =  GrRes\{ u)  «-►  GrAes£(u) 

U 

says  the  arbiter  eventually  satisfies  requesting  users.  The  condition  RtnRes%  D  GrResj 
says  that  if  users  return  the  resource,  then  the  arbiter  satisfies  all  requests.  We  now 
show  that  every  execution  of  Ei  satisfies  the  condition  RtnResi  D  GrRes j.  First, 
however,  we  prove  the  following  result,  the  inductive  statement  in  the  argument  that 
Ei  satisfies  the  condition  RtnResi  D  GrResi. 

Lemma  37:  Let  s  be  a  state  of  Aj  having  a  request  arrow  in  arrows  (u,  w).  Let  x  be 
an  execution  fragment  of  At  from  s  satisfying  the  condition  C,  A  RtnResi .  Then  the 
action  grant (w,v)  must  appear  in  x. 

Proof:  If  the  graph  G  is  viewed  as  a  tree  rooted  at  v,  then  w  can  be  viewed  as  the 
root  of  a  subtree  of  v.  We  proceed  by  induction  on  the  height  h  of  the  subtree  of  v 
rooted  at  w. 

Suppose  h  =  0.  In  this  case,  w  must  be  a  leaf  of  G ,  and  therefore  w  must  be  a 
user  node  and  v  an  arbiter  node.  Since  v  is  an  arbiter  node  and  arrows  ( v ,  w)  contains 
a  request  arrow,  Lemma  36  implies  the  edge  (v,w)  points  toward  the  root.  Therefore, 
arrows  (v,  w)  must  contain  a  grant  arrow.  Since  x  satisfies  RtnResi ,  the  user  w  must 
eventually  return  the  resource  to  the  arbiter,  and  hence  grant (w,  v)  must  appear  in  x. 

Suppose  h  >  0  and  the  inductive  hypothesis  holds  for  h  —  1.  We  first  show  that  x 
can  be  written  as  ax'  where  x/  is  an  execution  fragment  satisfying  CjA  RtnResi  in  whose 
initial  state  request  €  arrows  (v,  w)  and  w  is  the  root  (that  is,  grant  €  arrows  (u>',  w)  for 
some  node  w').  We  consider  two  cases.  First,  suppose  (v,u/)  does  not  point  toward  the 
root  in  «.  Since  arrows  (v,u/)  contains  a  request  arrow,  Lemma  36  implies  that  v  must 
be  a  user  node.  Since  user  nodes  are  leaves,  and  since  (v,w)  does  not  point  toward 
the  root,  the  root  must  be  at  v;  that  is,  arrows  (w,  t>)  must  contain  a  grant  arrow. 
Since  x  satisfies  RtnResif  the  user  v  must  eventually  return  the  resource  to  the  arbiter, 
so  grortf(v,w)  must  appear  in  x.  Therefore,  x  =  Pgrant (v,  u^x*  as  desired.  Now, 
suppose  (v,u>)  does  point  toward  the  root.  If  w  itself  is  the  root,  then  setting  x*  =  x 


we  are  done,  so  suppose  w  is  not  the  root.  If  for  some  node  u/  the  set  arrows  (tu,w') 
contains  a  request  arrow,  then  since  the  height  of  the  subtree  of  w  rooted  at  w'  must  be 
less  than  h,  the  inductive  hypothesis  for  h  -  1  implies  that  grant  (w1  ,w)  appears  in  z. 
Therefore,  x  =  0  grant  (w1,  w)z*  as  desired.  On  the  other  hand,  suppose  no  arrow  set 
arrows  (w,w')  contains  a  request  arrow.  Note  that  the  fact  that  h  >  0  implies  that  w 
is  not  a  leaf,  and  hence  that  w  is  an  arbiter  node.  Since  z  satisfies  Cj,  we  see  that  for 
some  node  w'  either  grant  (w1,  w)  or  request  (w,w')  appears  in  z.  If  grant  (w‘,  w)  appears 
in  z,  then  z  =  0  grant  (w',w)xf  as  desired.  If  request  (w,u/)  appears  in  z,  then  a  request 
arrow  is  placed  in  arrows  (w,  w'),  and  again  the  inductive  hypothesis  for  k  —  1  implies 
that  z  =  0  grant  (w'  ,w)xf  as  above. 

We  now  show  that  if  xf  is  an  execution  fragment  satisfying  Cj  A  RtnRest  in  whose 
initial  state  request  E  arrows  (v,w)  and  grant  E  arrows  (w',w )  for  some  node  w\  then 
grant  (wtv)  appears  in  z1.  From  this  it  will  follow  that  grant  (w,v)  appears  in  z  as 
well.  We  proceed  by  induction  on  d,  the  distance  from  w1  to  v  in  the  ordering  of 
the  nodes  adjacent  to  w  in  G.  Suppose  d  =  1.  Since  request  E  arrows  (v,w)  and 
grant  E  arrows  (u/' ,  w) ,  condition  Cj  implies  that  grant  (w,  y)  must  appear  in  if  for  some 
y  E  (tv'.v]  =  {v}.  Thus,  grant{ w,v)  must  appear  in  s'.  Suppose  d  >  1  and  the  inductive 
hypothesis  holds  for  d  —  1.  Suppose  the  inductive  hypothesis  does  not  hold  for  if: 
Suppose  that  grant  [w,v)  does  not  appear  in  if ,  and  hence  that  request  E  arrows (t/,w) 
in  every  state  appearing  in  x*.  As  in  the  case  of  d  =  1,  the  action  grant  (tv,  y)  must 
appear  in  xf  for  some  y  €  (w',v].  If  y  =  v  then  we  are  done,  so  suppose  y  ^  v.  If 
arrows (w,y)  contains  a  request,  then  the  inductive  hypothesis  for  h  —  1  implies  that 
grant  (w,  y)  appears  in  xf ,  and  the  inductive  hypothesis  for  d  - 1  implies  that  grant  (w,  v) 
must  also  appear  in  z'.  On  the  other  hand,  suppose  arrows  (w,y)  does  not  contain  a 
request  arrow.  Condition  Ci  implies  that  either  0rant(y,w)  or  request  (w,  y)  appears 
in  xf.  If  grant  [y,  w)  appears  in  if,  then  a  grant  arrow  is  placed  in  arrows  (y,w),  and  the 
inductive  hypothesis  for  d  —  I  implies  that  grant (u/,v)  appears  in  xf.  If  request {w,y) 
appears  in  x1,  then  a  request  arrow  is  placed  in  arrows(w,y),  and  grant (w,v)  must 
appear  in  xf  as  we  have  seen  above.  □ 

An  immediate  corollary  of  Lemma  37  is  the  following. 

Corollary  38:  Every  execution  of  E a  satisfies  the  condition  RtnRest  D  GrRes j. 

3.2.4  The  Execution  Module  E'2 

For  the  sake  of  exposition,  we  have  given  the  actions  of  A%  names  suitable  to  its  level 
of  abstraction,  rather  than  using  names  from  A\.  It  is  therefore  necessary  to  rename 
these  actions  before  showing  that  E j  solves  E i.  The  action  mapping  fi  from  Aj  to  A\ 
is  defined  to  map 


request  (u,  a)  to  refuest(«), 
grant(u,a)  to  return(u), 
grant  (a,  u)  to  grant(u), 

and  all  remaining  (internal)  actions  to  themselves.  We  will  denote  by  A'2  the  automaton 
fi(Ai),  and  in  general  we  will  denote  by  affixing  a  prime  to  its  name  the  entity  obtained 
by  renaming  its  actions  according  to  f\. 

3.2.5  The  Satisfaction  of  E\  by  ££ 

We  begin  the  proof  that  E\  satisfies  Ei  by  exhibiting  a  possibilities  mapping  from  A2 
to  A\.  The  mapping  hi  maps  the  state  a  of  A2  to  the  state  t  of  A\  such  that 

u  €  requesters  in  t  iff  request  €  arrows  (u,  a)  in  a 

holder  =  u  in  t  iff  grant  €  arrows  (a,  u)  in  a 

holder  =  a  in  t  iff  grant  &  arrows  (a,  u)  for  every  user  u  in  a 

These  conditions  ensure  that  a  user  is  a  requesting  user  in  t  iff  it  is  in  a,  and  that  a 

user  is  holding  the  resource  in  t  iff  it  is  in  a.  Since  all  states  of  A',  are  reachable,  and 
since  in  all  reachable  states  of  A'a  there  is  exactly  one  root,  this  mapping  takes  each 
state  of  A'a  to  a  singleton  set  of  states  of  A\. 

Lemma  SO:  The  mapping  kx  is  a  possibilities  mapping  from  A2  to  Ax. 

Proof:  The  automata  A',  and  Ai  clearly  have  the  same  external  action  signature.  If  s 
is  a  start  state  of  A],  then  a  single  arrow  set  arrows  (v,  a)  contains  a  grant  arrow  and  all 
other  arrow  sets  are  empty.  In  particular,  no  arrow  set  arrows  (u,  a)  contains  a  request 
arrow,  and  no  arrow  set  arrows  (o,  u)  contains  a  grant  arrow.  Therefore,  in  every  state 
of  hx(s)  the  set  requesters  of  requesting  users  is  empty,  and  holder  =  a.  Since  this  is 
the  start  state  of  Alt  we  see  that  if  s  is  a  start  state  of  A2,  then  a  start  state  of  A\  is 
contained  in  hi (a). 

Consider  the  action  x  =  request (u)  of  A2,  originally  the  action  request (u, a)  of  A). 
Suppose  s  and  t  are  reachable  states  of  A',  and  Ai,  respectively,  such  that  t  6  hi(s). 
The  action  x  is  an  input  action  of  both  automata,  and  hence  is  enabled  from  both  s 
and  t.  Suppose  s  s'  and  t  t1.  Since  x  adds  a  request  arrow  to  arrow*(u,a)  in  s', 
and  adds  u  to  requesters  of  requesting  users  in  t',  we  see  that  t'  6  hi  (s'). 

Consider  the  action  x  =  retum(u)  of  A',,  originally  the  action  return(u,a)  of  Aj. 
Suppose  s  and  t  are  reachable  states  of  A,  and  Ai,  respectively,  such  that  t  6  hj(s). 
Again,  x  is  an  input  action  of  both  automata,  and  hence  is  enabled  from  both  s  and  t. 
Suppose  j  — *  s'  and  t  t'.  The  definition  of  h\  implies  that  grant  6  arrows  (a,  u)  in  s 
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iff  holder  =  u  in  t.  If  both  conditions  are  false,  then  x  has  no  effect  on  either  a  or  t, 
so  t  €  hi(a)  implies  t'  €  hi  (s').  Suppose  both  conditions  are  true.  Notice  that  u  is  the 
unique  root  in  s.  The  action  x  moves  the  grant  arrow  from  arrows  (a,  u)  to  arrows  (u,  a) 
in  s',  and  x  sets  holder  to  a  in  t'.  Thus,  t'  e  hi  (s'). 

Consider  the  action  x  =  grant  ( u)  of  A2,  originally  the  action  grant  (a,  u)  of  Ai.  Sup¬ 
pose  s  and  t  are  reachable  states  of  A2  and  Ai,  respectively,  such  that  t  €  hi(e).  If  jr  is 
enabled  from  s,  then  request  6  arrows  (u,  a)  and  grant  €  arrows  (tv,  a)  for  some  node  w. 
Since  request  €  arrows  (u,  a)  in  s,  the  set  requesters  of  requesting  users  contains  u  in  t. 
Since  a  is  the  unique  root  in  s,  holder  =  a  in  t.  Thus,  x  is  enabled  from  t.  Suppose 
s  — *  s'  and  t  t'.  The  action  x  removes  the  request  arrow  from  arrows  (u,  a)  and 
moves  the  grant  arrow  to  arrows  {a,  u)  in  s',  and  x  removes  u  from  the  set  requesters 
of  requesting  users  and  sets  holder  to  u  in  t'.  Therefore,  t'  €  hi  (s'). 

Finally,  the  remaining  actions  request  (a,  u),  request  (a,  a'),  and  grant  (a,  a')  of  A, 
are  not  actions  of  Ai.  These  actions  do  not  affect  request  arrows  in  the  arrow  sets 
arrows  (u,  a)  or  grant  arrows  in  the  arrow  sets  arrows  (a,  u).  Therefore,  suppose  s  and  t 
are  reachable  states  of  A,  and  Ai  such  that  t  €  ht(s).  If  s  s'  is  a  step  of  A',,  then 
t  €  hi  (s').  It  follows  that  hi  is  indeed  a  possibilities  mapping  from  A't  to  Ai.  □ 

We  can  now  show  that  E\  satisfies  E\. 

Lemma  40:  E\  satisfies  Ex. 

Proof:  Let  x  be  an  execution  of  E'it  and  let  y  be  an  execution  of  Ax  corresponding 
to  y  under  hi.  First,  we  claim  that  (i)  if  y  satisfies  RtnRes[[u)  RtnRes‘( u),  then  x 
satisfies  RtnRes^(u)  ►  RtnRes\{u)' .  Suppose  s  is  a  state  of  RtnRes{{ u).  Since  grant  € 
arrows  (a,  u)  in  s,  we  see  that  holder  =  u  in  every  state  of  hi(s),  and  hence  that 
hx(RtnRes\[u))  C  iZtnAes^u).  Since,  in  addition,  f?tnf?es“(u)  C  RtnRes%( u)',  the  claim 
follows  by  Lemma  32.  Second,  we  claim  that  (ii)  if  x  satisfies  GrRes\[u)  «— ►  C7rjRes2(u)', 
then  y  satisfies  GrflesJ(u)  GriZe**(u).  Suppose  t  G  hi(s)  is  a  state  of  GrffesJ(u). 
Since  u  €  requesters  in  t,  we  see  that  request  €  arrows  (u,  a)  in  s,  and  hence  that 
hil(GrRes[{u))  C  GrRes\{ u).  Since,  in  addition,  Grf?es$(u)'  C  Crf?es“(u),  the  claim 
follows  by  Lemma  32.  From  observations  (i)  and  (ii)  it  follows  that  if  y  satisfies  RtnResx , 
then  x  satisfies  AtnAesj;  and  that  if  x  satisfies  GrResi ,  then  y  satisfies  GrResx.  Since  x 
satisfies  RtnRes^  D  GrRes j,  it  follows  that  y  satisfies  RtnResx  D  GrResx,  and  hence 
that  y  is  an  execution  of  Ex.  Since  sehed(x)\A\  =  sched(y),  and  since  E\  and  E\  have 
the  same  external  action  signature,  it  follows  that  fbeh(E'i)  C  fbeh(Ei ),  and  hence  that 
£]  will  satisfy  j£i.  □ 


3.3  The  Automaton  A3 

In  the  description  of  the  arbiter  given  by  the  previous  model,  the  arbiter  nodes  are 
intended  to  represent  processes  in  a  distributed  network  implementing  the  arbiter. 


Previous  models  have  given  global  descriptions  of  the  arbiter’s  behavior.  In  this  model 
we  actually  distribute  the  arbiter  by  modeling  each  process  as  a  separate  automaton. 
These  automata  describe  the  low-level  protocol  followed  by  each  process  in  the  arbiter’s 
implementation.  Notice  that  while  previous  models  have  acknowledged  the  asynchrony 
of  processor  step  times,  they  have  essentially  ignored  the  asynchrony  of  the  network’s 
message  system  by  assuming  instantaneous  message  delivery.  We  now  introduce  this 
asynchrony  into  the  model,  modeling  the  message  delivery  system  as  an  independent 
automaton.  By  composing  the  automata  modeling  arbiter  processes  with  the  automa¬ 
ton  modeling  the  message  delivery  system,  we  obtain  a  global  model  of  the  arbiter. 

In  order  to  model  asynchronous  message  delivery,  it  is  convenient  to  add  to  the 
graph  G  an  extra  arbiter  node  6aa<  (or  6a>a)  between  every  pair  of  adjacent  arbiter 
nodes  a  and  o'.  The  node  6aa>  acts  as  a  message  buffer  between  a  and  o':  The  node  o 
sends  a  message  to  a'  by  placing  an  arrow  on  the  edge  (a,  6a>a>),  and  the  message  system 
delivers  the  message  to  o'  by  placing  an  arrow  on  the  edge  (6a,a»,  o').  Since  they  function 
as  message  buffers,  we  will  hereafter  refer  to  the  nodes  6a>a>  as  buffer  nodes.  We  denote 
by  $  the  graph  obtained  from  G  by  the  addition  of  such  buffer  nodes.  Two  nodes 
(processes)  are  said  to  be  adjacent  in  $  if  they  are  separated  by  at  most  a  buffer  node; 
that  is,  if  they  are  user  or  arbiter  nodes  adjacent  in  the  graph  G.  Since  the  results  of 
the  previous  section  hold  for  arbitrary  connected,  acyclic  graphs,  and  since  Q  is  such  a 
graph,  these  results  hold  for  the  graph  Q .  We  therefore  fix  £  as  the  graph  underlying 
the  model  At.  Furthermore,  we  fix  as  the  set  of  start  states  of  At  those  start  states 
in  which  no  buffer  node  is  a  root.  In  such  states,  the  arbiter  holds  the  resource,  and 
no  undelivered  messages  are  pending.  We  note  that  with  the  added  structure  of  Q,  we 
can  prove  the  following  result  about  buffer  nodes  during  executions  of  At- 

Lemma  41:  Let  a  and  a!  be  adjacent  arbiter  nodes,  and  let  s  be  a  state  of  At.  If 
request  €  arrow*  (6aa<,  o')  or  grant  €  arrows  (o',  6a>a»),  then  request  6  arrows  (o,6ata«). 

Proof:  The  sets  arrows  (baai,  a')  and  arrows  (o',  bm<m>)  do  not  contain  request  or  grant 
arrows,  respectively,  in  any  start  state  of  At,  and  hence  every  start  state  satisfies 
the  hypothesis.  Suppose  s  is  a  reachable  state  of  At  satisfying  the  hypothesis,  and 
suppose  s  t  is  a  step  of  Aj.  We  claim  that  t  satisfies  the  hypothesis  was  well.  If 
x  =  request  (x,  y),  then  x  places  a  request  arrow  in  arrows(x,]j).  The  only  case  we  need 
consider  is  the  case  of  (z,y)  =  (6a,a>,a').  In  this  case,  x  is  enabled  only  if  o') 
points  toward  the  root,  and  there  is  a  request  in  arrows (v,6Bia<)  for  some  v.  If  v  =  o', 
then  Lemma  36  implies  that  the  edge  (a’,6a,a>)  also  points  toward  the  root.  Since 
Lemma  35  states  that  there  is  only  one  root,  this  is  clearly  impossible.  Therefore, 
we  must  have  v  =  a,  and  hence  that  t  satisfies  the  hypothesis.  If  x  =  grant  (x,y), 
then  x  places  a  grant  arrow  in  arrows  (x,y).  The  only  case  we  need  consider  is  the 
case  of  (x,y <  -  o', 6a  a<).  In  this  case,  x  is  enabled  only  if  there  is  a  request  arrow  in 
arrows  (6a  ,  a')  in  s.  By  hypothesis,  there  must  be  a  request  arrow  in  arrows  (a,  b„  „>) 

in  s,  and  hence  in  t.  Therefore,  t  must  satisfy  the  hypothesis.  The  lemma  follows  by  a 
simple  inductive  argument.  G 
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Note  that  we  do  not  model  any  message  asynchrony  between  users  and  the  arbiter:  User 
nodes  are  to  be  interpreted  as  ports  to  the  arbiter  through  which  the  users  communicate 
with  the  arbiter,  and  not  the  user  processes  themselves.  If  the  arbiter  is  to  be  used  in 
a  larger  system,  then  the  responsibility  of  modeling  the  message  delivery  between  the 
arbiter  and  the  rest  of  the  system  falls  on  the  model  of  the  larger  system’s  message 
delivery. 

The  previous  models  have  given  some  indication  of  the  behavior  required  of  arbiter 
processes.  In  the  first  place,  arbiter  processes  must  always  forward  a  request  for  the 
resource  in  the  direction  of  the  resource.  Since  the  network  is  acyclic,  the  process  is 
able  to  determine  the  direction  of  the  resource  by  remembering  the  direction  in  which  it 
last  forwarded  the  resource.  Furthermore,  arbiter  processes  holding  the  resource  must 
forward  the  resource  to  a  requesting  process.  In  particular,  if  arbiter  process  a  receives 
the  resource  from  process  v,  then  a  must  grant  the  resource  to  the  first  requesting 
process  after  v  in  a  fixed  ordering  of  its  neighbors.  Therefore,  the  state  of  am  arbiter 
process  is  determined  by  a  set  of  processes  from  which  it  has  received  a  request,  the 
link  over  which  the  resource  was  last  sent,  whether  or  not  the  process  is  holding  the 
resource,  and  whether  or  not  a  request  has  been  forwarded  in  the  direction  of  the 
resource.  For  each  arbiter  process  a  (each  arbiter  node  of  the  graph  G),  we  construct 
an  automaton  Aa  modeling  the  process  a. 

The  behavior  required  of  the  message  system  is  very  simple.  The  system  must  be 
able  to  accept  messages  for  delivery,  and  ensure  that  every  message  sent  is  eventually 
delivered.  The  state  of  the  message  system  is  simply  a  collection  of  undelivered  mes¬ 
sages,  together  with  their  destinations.  We  construct  an  automaton  M  to  model  the 
asynchronous  message  communication  system. 

3.3.1  The  States  of  Aa  and  M 

As  mentioned  above,  a  state  of  A.  is  determined  by  a  set  requesting  of  requesting 
processes  adjacent  to  a,  a  variable  lastforward  indicating  the  adjacent  process  to  which  a 
last  forwarded  the  resource,  a  binary  flag  holding  indicating  whether  or  not  a  is  holding 
the  resource,  and  a  binary  flag  requested  indicated  whether  or  not  a  has  requested  the 
resource  since  last  holding  the  resource.  To  define  the  start  state  of  Am,  we  designate 
one  of  the  arbiter  processes  and  the  initial  holder  of  the  resource.  The  start  state  of  Aa 
is  a  state  in  which  the  set  requesting  of  requesting  processes  is  empty;  the  variable 
lastforward  is  set  to  the  process  adjacent  to  a  on  the  path  from  a  to  the  process 
currently  holding  the  resource,  or  to  any  adjacent  process  if  a  is  the  initial  holder;  the 
flag  holding  is  set  depending  on  whether  a  is  the  initial  holder;  and  the  flag  requested 
is  set  to  false.  Notice  that  there  are  several  possible  initial  states  for  the  initial  holder 
since  lastforward  may  be  set  to  any  of  its  adjacent  processes,  but  that  the  initial  state 
of  the  remaining  processes  is  unique. 


A s  indicated  above,  the  state  of  Af  is  determined  by  a  set  messages  of  messages 
to  deliver  (either  request  or  grant  messages)  together  with  the  identity  of  the  sender 
and  receiver  of  the  message.  More  formally,  messages  is  a  set  of  triples  of  the  form 
(v,  w,  request)  or  (v,  w,  grant)  denoting  messages  to  be  delivered  from  v  to  tv.  The  initial 
state  of  M  is  the  state  in  which  messages  is  empty,  the  state  in  which  no  messages  are 
undelivered. 

3.3.2  The  Actions  of  Aa  and  M 

The  actions  of  A «  are  given  in  Figure  3.5.  The  input  actions  are  those  actions  of  the 
form  receiverequest(v,a)  and  reeeivegront(vfa),  and  the  output  actions  are  of  the  form 
sendrequest{a,v)  and  sendgrant(a,v),  where  v  is  a  node  (process)  adjacent  to  a  in  the 
graph  Q.  These  actions  behave  just  as  described  above.  There  are  no  internal  actions 
of  A 4. 

The  actions  of  M  are  given  in  Figure  3.6.  The  input  actions  are  those  actions  of 
the  form  sendrequest  (a,  a')  and  sendgrant  (a,  a1),  and  the  output  actions  are  of  the  form 
receiverequest(a,  o')  and  reeeivegrant  (a,  a'),  where  a  and  a!  are  adjacent  arbiter  nodes 
of  Q.  These  actions  accept  messages  to  be  delivered  by  placing  them  in  the  message 
buffer  messages,  and  deliver  them  by  removing  them  from  the  buffer.  There  are  no 
internal  actions  of  M. 

3.3.3  The  Automaton 

The  composition  of  the  automata  A#  modeling  the  arbiter  processes  together  with 
the  automaton  M  modeling  the  message  system  yields  a  global  model  of  the  arbiter. 
However,  we  must  hide  actions  that  are  inherently  internal  to  the  arbiter.  Therefore, 
we  define  the  automaton  As  to  be  the  composition  of  the  automata  A,  together  with 
the  automaton  M,  after  hiding  all  output  actions  of  the  composition  except  those  of  the 
form  sendgrant  (a,  u)  (where  a  and  u  are  adjacent  arbiter  and  user  nodes,  respectively). 

3.3.4  The  Execution  Module  £3 

As  mentioned  in  the  introduction  to  this  model,  an  arbiter  process  a  is  required  to 
forward  all  requests,  and  to  grant  the  resource  to  a  requesting  process  if  the  arbiter 
process  holds  the  resource.  Let  v  and  w  be  two  nodes  adjacent  to  the  arbiter  node  a, 
and  let  us  define  the  following  sets  of  states  and  actions. 


Input  Action*: 

receiver  equest^v ,  a) 
effect*: 

requesting  <—  requesting  U  {«} 

receivegrant{v ,  a) 

effect*: 

if  holding  =  false  and  lastforward  —  v  then 
holding  *-  true 
requested  *—  false 

Output  Action*: 

sendrequest(a,  v) 
precondition*: 

requesting  ^  0 
requested  =  false 
holding  =  false 
lastforward  =  v 
effects: 

requested  *—  true 

sendgrant(a ,  v) 

precondition*: 

v  €  requesting 
holding  =  tree 
lastforward  =  w 
V  £  requesting  for  all  y  €  (w,  v) 
effect*: 

requesting  «—  requesting  -  {«} 
lastforward  —  v 
holding  «—  false 


Figure  3.5:  The  Actions  of  Aa. 


Input  Actions: 

aendrequest  (a,  a!) 
effects: 

messages  «—  messages  U  {(a, a',  request )} 

sendgrant  (a,  a') 
effects: 

messages  *—  messages  U  {(a, a',  grant)} 

Output  Actions: 

rcceiverequest[a,  a') 
preconditions: 

(a,  a',  request)  g  messages 
effects: 

messages  «—  messages  —  {(a, o',  request)} 

reeeivegrant  (o,  o') 
preconditions: 

(a, a' ,  grant)  6  messages 
effects: 

messages  *—  messages  —  {(a, a',  grant)} 

Figure  3.6:  The  actions  of  M. 
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FwdReq*a{v)  =  {36  states  (Aa)  :  requesting  ^  0, 

requested  =  /a/se, 
holding  =  false ,  and 
last} or  ward  =  v  in  3} 

fWf?efla(t>)  =  {reeeivefnmf  (t/,a),«endre$ueat(a,v)} 

/'tiKfC7r*(t;,u>)  =  {3  €  states(Aa)  :  v  6  requesting 

holding  =  true,  and 
last  for  ward  =  tu  in  3} 

Fwd(7r“(v,u/)  =  {sendgrant(a,y)  :  y  €  (u>,v]} 


The  condition 


FwdReqa  =  /\  /WReg*  (t>)  <— *  Fu;dReg*(t/) 


says  that  the  arbiter  process  a  having  received  a  request  and  not  holding  the  resource 
will  either  forward  a  request  for  the  resource  or  receive  the  resource  (without  having 
requested  it,  perhaps  from  a  user).  The  condition 

FwdGra  =  f\FwdGr*a{y)  *-»  FwdGr\{v) 

« 

says  that  the  arbiter  process  a  holding  the  resource  and  having  received  a  request  will 
eventually  forward  the  resource  to  a  requesting  process.  The  condition 

Ca  ~  FwdReqa  A  FwdGr a 

is  the  desired  correctness  condition  for  the  arbiter  process  a.  We  note  the  following. 
Lemma  42:  Every  fair  execution  of  Aa  satisfies  Ca. 

Proof:  Let  3  be  a  state  of  FwdReq’a(v)  and  let  z  be  an  execution  fragment  of  A„  from  3. 
If  neither  receivegrant  (v ,  a)  nor  eendrequcst  (a,  v)  appear  in  z,  then  sendrequest(a,v)  is 
enabled  from  every  state  appearing  in  z.  Therefore,  every  fair  execution  of  Aa  satisfies 
FwdRcq„.  Similarly,  let  3  be  a  state  of  FwdGr* (v,  w)  and  let  z  be  an  execution  fragment 
of  Aa  from  3.  If  no  action  of  FwdGr“(v,  w)  appears  in  z,  then  again  an  action  from  this 
set  is  enabled  from  every  state  appearing  in  z.  Therefore,  every  fair  execution  of  Aa 
satisfies  FwdGra.  It  follows  that  every  fair  execution  of  Aa  satisfies  Ca.  □ 

We  let  the  execution  module  Ea  =  Fair(Aa).  Recall  that  an  object  O  solves  (the 
problem  specified  by)  an  object  O'  only  if  it  is  implementable.  Since  Ea  is  part  of  our 
solution  to  the  arbiter’s  pro  '“tn  specification,  it  is  necessary  to  show  that  Ea  (aa  well  as 
every  other  execution  module  defined  at  this  low  level  of  abstraction)  is  implementable. 

Lemma  43:  Ea  is  implementable. 
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We  must  also  require  that  the  message  system  deliver  all  messages  sent.  Let  a 
and  a !  be  two  adjacent  arbiter  processes,  and  let  us  define  the  following  sets  of  states 
and  actions. 


DelReq‘u(a,  a') 
DelRtt/lda,  a!) 


{a  €  states  (M)  :  (a,  a* ,  request)  €  messages  in  s} 
{receive  request  (a,  a')} 


DelGr^(ata') 

De/Gr£f(a,a') 


{s  €  states {M)  :  (a,  a1,  grant)  €  messages  in  s) 
{receivegrant  (a,  a')} 


If  we  let 


DelRequ  =  f\  DelRe^(a, a')  *— ►  DclRcq,u(a,a') 


and 


then  the  condition 


DelGr*  =  f\  DelG^a.a!)  «-  De/G»^(o,o'), 
Cm  =  DelReq^  A  DelGr m 


says  that  messages  sent  are  always  delivered.  We  denote  by  Em  the  execution  module 
of  M  with  the  executions  satisfying  Cm- 


Lemma  44:  Em  is  implementable. 

Proof:  It  is  easy  to  construct  an  automaton  M*  with  the  action  signature  of  Em  whose 
fair  executions  are  executions  of  Em-  The  automaton  M'  keeps  messages  to  be  delivered 
in  a  FIFO  buffer,  and  delivers  them  in  the  order  in  which  they  are  received  for  delivery. 

□ 

Finally,  we  define  E3  to  be  the  composition  of  the  execution  modules  Eu  and  Em 
after  hiding  the  internal  actions  of  A3.  As  a  result  of  Lemma  26,  we  have  the  following. 


Lemma  45:  Ez  is  implementable. 


3.3.5  The  Execution  Module  E 3 

As  with  the  execution  module  Ez,  it  is  necessary  to  rename  the  actions  of  Ez  to  be 
consistent  with  the  names  of  Ez.  As  mentioned  when  we  defined  the  buffer  nodes  &«,«>, 
the  arbiter  node  a  sends  a  message  to  the  arbiter  node  a'  by  placing  an  arrow  on  the 
edge  (a,  6a  ai)  between  a  and  the  buffer  node  and  the  message  system  delivers  the 
message  by  placing  an  arrow  on  the  edge  o')  between  the  buffer  node  and  o'.  An 
arbiter  node  and  user  node  communicate  by  placing  an  arrow  on  the  edge  between 
them.  Therefore,  if  o  is  an  arbiter  node  and  a’  and  u  are  arbiter  and  user  nodes, 
respectively,  adjacent  to  a  in  £,  we  define  the  action  mapping  /j  to  map 
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reeeiverequest(u,a)  to  request  (u,  a) 
reeeivegrant(u,a)  to  grant  (u,  a) 
scndrequest  (a,  u)  to  request  (a,  u) 
sendgrant  (a,  u)  to  grant  (a,  u) 

receiver equest{a\  a)  to  request  (ba>  m,  a) 
receivegrant  (a1 ,  a)  to  grant  (6a>,« ,  a) 
scndrequest  (a,  a1)  to  request  (a, 
sendgrant  (a,  a')  to  9rant(a,6B|B«) 

We  will  denote  by  Aa  the  automaton  /i(Aj),  and  in  general  we  will  denote  by  affixing 
a  prime  to  its  name  the  entity  obtained  by  renaming  its  actions  according  to  /j. 

3.3.6  The  Solution  of  E2  by  E'3 

We  begin  the  proof  that  Ea  satisfies  Et  by  exhibiting  a  possibilities  mapping  from  Aa 
to  Aj.  In  order  to  define  this  mapping,  it  will  be  necessary  to  refer  to  state  variables 
from  each  of  the  components  of  A'a.  While  the  name  of  the  state  variable  messages 
of  Af'  is  unique  to  M',  the  remaining  components  share  variable  names.  In  order  to 
avoid  ambiguity,  we  will  indicate  the  component  to  which  a  state  variable  belongs  by 
subscripting  the  variable  with  an  appropriate  identifier.  For  example,  the  set  requesting 
of  requesting  processes  in  A'a  will  be  denoted  by  requesting a.  The  mapping  h3  maps 
the  state  s  of  Aa  to  the  set  of  states  t  of  Aj  satisfying  the  following  conditions: 

Ul  request  €  arrows  (u,  a)  iff  u  £  requesting^ 

U 2  grant  £  arrows  [u,  a)  iff  holding #  =  true  and  lastforward  t  =  u 

UZ  request  £  arrows  (a,  u)  iff  requested  a  =  true  and  lastforward  t  —  u 

U 4  grant  £  arrows  (a,  u)  iff  holding a  =  false  and  lastforward  a  =  u 

Al  request  £  arrows  (bai  a,  a)  iff  o'  €  requesting s 

A2  grant  €  arrows  (4**,*,  o)  iff  holding a  =  true  and  lastforward m  =  a! 

A3  request  €  arrows  (a,  ba>a>)  iff  requested a  =  true  and  lastforward a  =  a! 

A4  grant  €  arrows  (o,  6a)(1»)  iff  (a,  a' ,  grant)  €  messages 

1 1  request  €  arrows  (a,  6a,a»), 
request  £  arrows (6a,a», o'), 

and  0rant  £  arrows  (a',  ba,a>)  iff  (a,  a' ,  request)  £  messages 

12  (<*,  points  toward  the  root  iff  holding a  =  false  and  lastforward a  =  a' 

The  conditions  U 1  -  1/2  and  Al  —  A4  are  straightforward.  They  say  that  the  arbiter 
process  a  has  received  a  request  from  a  process  v  in  t  iff  v  is  in  a’s  set  requesting  of 
requesting  processes  in  s,  and  that  a  has  received  the  resource  from  v  in  t  iff  a  holds  the 


resource  in  #  and  last  sent  (and  hence  received)  the  resource  from  v.  Similarly,  a  has 
forwarded  a  request  for  the  resource  in  t  iff  a  has  sent  a  request  in  the  direction  it  last 
forwarded  the  resource  in  s.  A4  says  that  the  resource  is  in  transit  between  a  and  a! 
in  t  iff  there  is  a  grant  message  from  a  to  a'  in  the  message  buffer  messages  in  s.  C/4 
says  that  the  user  u  has  the  resource  in  t  if  in  s  the  node  a  last  forwarded  the  resource 
to  u  and  has  not  received  the  resource  since.  Conditions  71  and  72  are  invariants  that 
must  be  preserved  by  the  mapping.  71  says  that  a  state  with  a  request  in  transit  must 
map  only  to  states  satisfying  Lemma  41.  72  says  that  the  value  of  lastforward  correctly 
records)  the  direction  of  the  resource  in  the  network.  We  now  have  the  following. 

Lemma  40:  The  mapping  ht  is  a  possibilities  mapping  from  A'9  to  Aj. 

Proof:  The  action  mapping  /j  has  renamed  the  actions  of  As  so  that  A,  and  Aj  have 
the  same  external  action  signature.  Let  *  be  a  start  state  of  A's.  For  every  arbiter 
process  a  in  s,  the  set  requesting a  of  requesting  processes  is  empty,  and  requested a  is 
set  to  false .  It  follows  by  Ul,  173,  Al,  and  A3  that  no  arrow  set  of  any  state  in  hj (a) 
contains  a  request  arrow.  Furthermore,  the  initial  holder  a  in  s  has  set  its  flag  holding , 
to  true;  all  other  processes  a'  have  set  holding  to  false,  and  last  for  ward  to  the  node 
in  the  direction  of  the  resource;  and  no  grant  message  is  pending  in  the  message  buffer 
messages.  It  follows  by  C/2,  U4,  A2,  and  A4  that  there  is  precisely  one  root  in  every 
state  of  ht[s).  Therefore,  /ij(a)  contains  a  start  state  of  Aj  as  desired. 

Consider  the  action  x  =  request  (u,  a)  of  Aj,  originally  the  action  recei  ve  request  (u,  a) 
of  Aj.  Suppose  a  and  t  are  reachable  states  of  A's  and  As,  respectively,  such  that 
t  6  hj(s).  The  action  x  is  an  input  action  of  both  automata,  and  hence  is  enabled  from 
both  a  and  t.  Suppose  a  s'  and  t  A  t\  To  show  that  t'  6  hj(a'),  we  must  show 
that  U 1  holds.  However,  x  adds  u  to  the  set  requesting a  of  requesting  processes  is  s', 
and  adds  a  request  arrow  to  the  set  arrow# (u,  a)  in  t',  and  hence  U 1  holds.  Therefore, 

t'  €  Ma')- 

Consider  the  action  ir  =  grant [u, a)  of  A's,  originally  the  action  reeeivegrant(u,a) 
of  As.  Suppose  a  and  t  are  reachable  states  of  A's  and  As,  respectively,  such  that 
t  €  hs(a).  Since  x  is  an  input  action  in  both  automata,  x  is  enabled  from  both  a 
and  t.  Suppose  s  s'  and  t  t'.  We  see  by  £7 4  that  there  is  a  grant  arrow  in  the  set 
arrows  (a,  u)  of  t  iff  holding  t  =  false  and  lastforward #  =  u  in  a.  If  both  conditions  are 
false,  then  x  has  no  effect  on  either  state,  and  hence  t  6  hj(s)  implies  t‘  e  hj(#').  On 
the  other  hand,  suppose  both  conditions  are  true.  To  show  t'  6  hs(a'),  we  must  show 
that  C/2,  (73,  and  U 4  hold.  Notice  that  lastforward ,  =  u  in  s'.  First,  x  sets  holding „ 
to  true  in  s',  and  adds  a  grant  arrow  to  arrows  (u,  a)  in  t',  so  U2  holds.  Second,  x  sets 
requested a  to  false  in  s',  and  removes  any  request  arrow  from  the  set  arrow# (a,  u)  in  t 
so  U 3  holds.  Finally,  since  x  sets  holding ,  to  true  in  s',  the  fact  that  x  moves  the  grunt 
arrow  from  arrows  (a,  u)  to  arrow*  (u,  a)  implies  that  U4  holds.  Therefore,  t'  €  ht(s'). 

Consider  the  action  x  =  request  (a,  u)  of  Aj,  originally  the  action  scndrequest(a,u ) 
of  As.  Suppose  a  and  t  are  reachable  states  of  A's  and  Aj,  respectively,  such  that 
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t  €  hj(s).  If  a  is  enabled  from  a,  then  the  set  requesting  a  of  requesting  processes  is 
nonempty  in  s,  so  U\  and  A1  implies  that  some  set  arrows  (w,  a)  contains  a  request 
arrow  in  t.  Furthermore,  since  holding a  =  false  and  lastforward .  =  u  in  s,  we  have 
by  C/4  that  arrows  (a,  u)  contains  a  grant  arrow  in  t,  and  hence  that  the  edge  (o,u) 
points  toward  the  root  in  t.  Finally,  since  requested.  =  false  in  s,  by  UZ  we  have  that 
arrows  (o,  u)  does  not  contain  a  request  arrow.  Therefore,  ir  is  enabled  from  t.  Suppose 
s  —*  s'  and  t  t1.  To  see  that  t'  €  h,(s'),  we  must  show  that  U 3  holds.  Notice  that  fl¬ 
eets  request edi  to  true  in  s',  and  that  lastforward .  =  u  in  s'.  Since  a  adds  a  request 
arrow  to  arrows(a,u)  in  t',  we  see  that  UZ  holds.  Therefore,  t'  €  /ij(s'). 

Consider  the  action  a  =  grant  (a,  u)  of  A's,  originally  the  action  sendgrant(a,u) 
of  A3.  Suppose  s  and  t  are  reachable  states  of  Aj  and  Aj,  respectively,  such  that 
t  €  hj(s).  If  a  is  enabled  from  s,  then  u  is  contained  in  the  set  requesting  m  of  requesting 
processes  in  s,  and  U 1  implies  that  arrows  (u,  a)  contains  a  request  arrow.  Furthermore, 
holding .  =  true  and  lastforward a  =  w  in  s,  so  C/2  and  A2  imply  that  arrows  {bw<a,  a) 
(or  arrows  (w,  a)  if  w  is  a  user  node)  contains  a  grant  arrow  in  t.  In  addition,  since 
y  §?  requesting a  for  all  y  €  (u>,  u)  in  s,  t/I  and  A1  imply  that  in  t  no  set  arrows (6,i#,  o)  (or 
arrows  (y,  a)  if  y  is  a  user  node)  contains  a  request  arrow  for  any  y  6  (w,  u).  Therefore,  a 
is  enabled  from  t.  Suppose  s  s'  and  t  A  t'.  To  show  that  t'  €  h*(s'),  we  must  show 
that  £/l,  172  and  A2,  U 3  and  A3,  and  U\  hold.  First,  the  action  a  removes  u  from 
requesting,  in  s',  and  removes  a  request  arrow  from  arrows[v,a)  in  t',  so  Ul  holds. 
Second,  since  holding .  is  set  to  false  in  s',  and  since  a  is  not  a  root  in  t',  U2  and  A2 
hold.  Third,  since  holding .  =  true  in  s,  we  see  that  requested .  =  /a/se  in  s  and  hence 
in  s',  so  V 3  and  A3  hold.  Finally,  since  a  sets  holding .  to  /alee  and  lastforward .  to 
u  in  s',  and  since  a  adds  a  grant  arrow  to  arrows(a, u)  in  t',  we  see  that  U4  holds. 
Therefore,  t'  6  hj(s'). 

Consider  the  action  a  =  request (6B< a)  of  Aj,  originally  reeeiverequest(a',  a)  of  Aj. 
Suppose  s  and  t  are  reachable  states  of  A,  and  A],  respectively,  such  that  t  €  h3(s). 
If  a  is  enabled  from  s,  the  set  messages  of  undelivered  messages  in  s  must  contain  a 
request  message  from  a'  to  a.  It  follows  by  /I  that  in  t  the  set  arrows  (a! ,  6„. .)  contains 
a  request  arrow,  the  set  arrows  (6a<,«,  a)  does  not  contain  a  request  arrow,  and  the  set 
arrows  (a,  6.  ..)  does  not  contain  a  grant  arrow.  Since  arrows  (a'  ,6«',«)  contains  a  request 
arrow,  Lemma  36  implies  that  (a',6a<>a)  points  toward  a  root.  This  together  with  the 
fact  that  arrows  (a,  6a*.«)  does  not  contain  a  grant  arrow  implies  that  (ba>  .,a)  points 
toward  the  root  as  well.  Therefore,  the  action  a  is  enabled  from  t.  Suppose  s  s'  and 
t  -Z*  t'.  In  order  to  see  that  t'  G  hj(s'),  we  must  show  that  A1  and  II  hold.  First,  a 
adds  a'  to  the  set  requesting .  of  requesting  processes  in  s',  and  a  adds  a  request  arrow 
to  arrows  (6a>,a,  a)  in  t',  so  A1  holds.  Second,  a  removes  a  request  message  from  a '  to  a 
from  the  set  messages  of  undelivered  messages  in  s',  and  a  adds  a  request  arrow  to 
arrows (6a«., a),  so  71  holds.  Therefore,  t'  6  hj(s'). 

Consider  the  action  a  =  grant(6a<,a,a)  of  A'3,  originally  the  action  reccivegrant  (a1 ,  a) 
of  Aj.  Suppose  s  and  t  are  reachable  states  of  Aj  and  Aj,  respectively,  such  that 
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t  €  Aa(s).  If  *  La  enabled  from  s,  the  set  messages  of  undelivered  messages  in  s  must 
contain  a  grant  message  from  a '  to  a.  By  A4  we  see  that  the  set  arrows  (o',  6a«>a)  contains 
a  grant  arrow  in  t.  Lemma  41  implies  that  the  set  arrows  (a,  6a,a<)  must  contain  a  request 
arrow.  Since  the  degree  of  the  buffer  node  6a,a<  is  2,  we  see  that  *  is  enabled  from  t. 
Suppose  a  s'  and  t  A  t1.  Since  the  set  arrows  (a,  bmA>)  contains  a  request  arrow  in  t. 
Lemma  36  implies  that  the  edge  (a,ba,a»)  points  toward  the  root.  By  72  we  see  that 
holding .  =  false  and  lastforward^  =  a!  in  s.  Therefore,  to  see  that  t‘  €  Aj(s'),  we 
must  show  that  A2,  A3,  AA,  and  12  hold.  First,  k  sets  holding a  to  true  in  s'.  Notice 
that  lastforward^  =  a!  in  s,  and  therefore  in  s'  a*  well.  Since  *  adds  a  grant  arrow  to 
arrows  (6a.ia,  a)  in  t' ,  we  see  that  A2  holds.  Second,  *  sets  requested a  to  false  in  s',  and  r 
removes  a  request  arrow  from  arrows  (a,  6aa.)  in  f\  so  A3  holds.  Third,  x  removes  a 
grant  message  from  a'  to  a  from  the  set  messages  of  undelivered  messages  in  s',  and  r 
removes  a  grant  arrow  from  arrows  (a',  6a>>a)  in  t',  so  >44  holds.  Finally,  since  holding a 
is  set  to  true  in  s',  it  is  easy  to  see  that  12  holds.  Therefore,  t'  €  h* (s'). 

Consider  the  action  x  =  reguest  (a,  6a  a>)  of  Aj,  originally  the  action  sendrequest  (a,  a') 
of  As.  Suppose  s  and  t  are  reachable  states  of  A's  and  As,  respectively,  such  that 
t  €  hj(s).  If  x  is  enabled  from  s,  then  the  set  requesting m  of  requesting  processes  is 
nonempty  in  s,  and  hence  by  (71  and  >41  some  set  arrows  (w,  a)  of  t  contains  a  reguest 
arrow.  Furthermore,  since  holding  ^  =  false  and  lastforward  m  =  a!  in  s,  by  72  we  see 
that  the  edge  (a,  6aa.)  points  toward  the  root  in  t.  Finally,  since  requesting .  =  /alee 
in  s,  by  >43  we  see  that  there  is  no  request  arrow  in  arrows  (a,  6a,a»)  in  t.  Therefore,  v 
is  enabled  from  t.  Suppose  a  s'  and  t  t'.  To  see  that  t'  6  hj(s'),  we  must  show 
that  >43  and  71  hold.  Notice  that  x  sets  requested a  to  true  in  s',  and  places  a  request 
arrow  in  arrows  (a,  6a>a«)  in  t'.  Since  lastforward  m  =  a'  in  s  and  hence  in  s',  we  see  that 
>43  holds.  Notice  that  requested a  =  false  in  s.  Since  lastforward m  —  a'  in  s,  >43  implies 
that  arrows  (a,  6a,a«)  does  not  contain  a  request  arrow  in  t.  Lemma  41  implies  that  there 
is  no  request  arrow  in  arrows  (6a,a»,  a')  and  no  grant  arrow  in  arrows  (a*,  6a,«')  i®  *»  *®d 
hence  the  same  is  true  in  t'.  Since  *  adds  a  request  arrow  to  arrows  (a,  ba>a»)  in  t\  and 
adds  a  reguest  message  from  a  to  a'  to  the  set  messages  of  undelivered  messages  in  s', 
we  see  that  71  holds.  Therefore,  t1  6  hj(s'). 

Finally,  consider  the  action  *  =  grant  (a,  b.^>)  of  A',,  originally  sendgrant  (a,  a')  of  A*. 
Suppose  s  and  t  are  reachable  states  of  A's  and  Aj,  respectively,  such  that  t  6  ha(a). 
If  it  is  enabled  from  s,  then  since  a'  €  requesting #  in  s,  we  see  by  A1  that  arrows  (6a.a,  a) 
contains  a  reguest  arrow  in  t.  Since  holding a  =  true  and  lastforward #  =  w  in  s,  we  see 
by  (72  and  A2  that  a  grant  arrow  must  be  contained  in  arrows  (bm>m,  a)  (or  arrows  (w,  a) 
if  w  is  a  user  node)  in  t.  Furthermore,  since  y  £  requesting 4  for  all  y  €  (u/,a')  in  s,  we 
see  by  (73  and  A3  that  no  request  arrow  is  contained  in  arrows(6v,a,a)  (or  arrows (y,  a) 
if  y  is  a  user  node)  in  t.  Therefore,  n  is  enabled  from  t.  Suppose  a  a'  and  t  t'. 
To  see  that  t'  6  hj(a'),  we  must  show  that  Al,  A2  and  72,  A4,  71,  and  72  hold.  All 
except  71  are  straightforward,  so  we  show  71.  Notice  that  arrows (6a>,a,  a)  contains  a 
request  arrow  in  t.  By  71,  there  is  no  undelivered  request  message  from  a'  to  a  in  the 
set  messages  of  s,  and  hence  in  s'.  However,  x  puts  a  grant  arrow  in  arrows  (a,  ba  o<), 
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so  /I  holds.  Therefore,  t'  €  hj(a').  □ 

Having  exhibited  a  possibilities  mapping  from  A's  to  At,  we  now  use  this  map¬ 
ping  together  with  Lemma  33  to  show  that  Ea  satisfies  Ej.  Before  using  Lemma  33, 
however,  we  must  translate  the  local  correctness  conditions  C’a  and  Cm  for  E[  and 
respectively,  into  a  global  correctness  condition  for  E'a.  We  use  Lemma  34  to  recharac¬ 
terize  Ea  in  this  way.  Let  a  and  a!  be  adjacent  arbiter  nodes,  and  let  v  be  an  arbitrary 
(user  or  arbiter)  node  adjacent  to  a  in  $.  Let 

FwdRtq\[y)'  =  {a  6  »tates(Aa)  :  a\A\  €  FwdRtq*t{y)} 

FwdGr^(v)1  =  {a  6  state*(A's)  :  a| A'0  €  FtudGr^(v)} 

DtlRaf^a^a!)'  =  {a  6  atatt9{A'i)  :  a\Af  €  DtlRttf‘ki{a,a>)') 

DtlGt\4{aya!y  =  {a  €  state*(A's)  :  a|Af*  €E  D«/Cr^(o,o')}  . 

Furthermore,  let 

FtvdRcJt  =  A  FwdReq*t(v)'  FwdReq“(v)' 

9 

FwdG r*.  =  A  FwdGr^ivY  *-*  FwdGr^v)'. 

9 

DtlRerfu  =  A  DelRetfu{aya,y  —  DtlRt<fM{a,a’)' 

DclGS jy.  =  A  DtlGr'u{a,a,y  *-  DelGr*M{afa'y. 

Finally,  let 

C'm  =  FwdReJu  A  FvodG^ 

Cm  =  DtlRcifM  A  DclGi'u. 

If 

c;  =  A<?;  a  c;, 

ft 

then  the  following  is  an  immediate  result  of  Lemma  34. 

Lemma  47:  E'a  is  the  execution  module  of  A'a  with  the  executions  of  A's  satisfying  C's. 

Having  made  this  transformation  from  local  to  global  correctness  conditions,  we 
now  use  Lemma  33  to  show  that  Ea  satisfies  £j. 


Lemma  48:  Ea  satisfies  £j. 


Proof:  Let  a  and  a'  be  adjacent  arbiter  nodes,  and  let  v  and  w  be  arbitrary  nodes 
adjacent  to  a.  If  v  is  an  arbiter  node,  then  let  v*  be  the  buffer  node  6a  ,  between  a 
and  v;  and  let  v1  be  the  node  v  itself  if  v  is  a  uaer  node.  The  node  v'  is  simply  the  node 
of  Q  adjacent  to  a  such  that  the  edge  (a,  v')  points  toward  v.  Let  to'  be  the  analogous 
node  with  respect  to  to.  We  will  show  that 

1.  ht1(FwdReq2(a,v>))  C  FwdReq*(v)* 

2.  H^fFwdReq J (&*,•',  «0)  £  DelRafkt{a,a,y 

3.  h^1  {FwdGr\(a,  t>\w'))  C  FwdGrJ(t>,  w)1,  and 

4.  hj1(/WGi’j(&ata»,a,a'))  C  DelG^el  ,a)' 

Since  it  is  easy  to  see  from  the  definition  of  ft  and  the  following  sets  that 

1.  FwdGt*(v)'  C  FwdReq\(a,v'), 

2.  DelRe^ld(a,a)'  C  FwdRtq\{b,<  m,a), 

3.  FwdGr^(v,w)'  C  FwdGr5(a,v',w'),  and 

4.  DelGi\i{a\ay  C  FwdGr^(ba'm,a), 

it  will  follow  by  Lemma  33  that  E\  satisfies  E%. 

First,  suppose  t  €  h,(a)  is  a  state  of  FwdReq\(a,  o'),  and  let  us  show  that  s  is  a  state 
of  FwdReq\(v)'.  Since  some  set  arrows  (to,  a)  of  t  contains  a  request,  we  see  by  U 1  and 
Al  that  the  set  requesting  %  of  requesting  processes  is  nonempty.  Since  (a,v')  points 
toward  the  root  in  t,  we  see  by  C/4  and  12  that  holding  m  =  false  and  last  forward  a  =  v 
in  s.  Since  the  set  arrows  (a,  v')  does  not  contain  a  request  arrow  in  t,  the  fact  that 
lastforward ,  =  v  together  with  C/3  and  j43  imply  that  requested  %  =  false.  Therefore, 
s  €  FwdReq\{y)'. 

Second,  suppose  t  6  hj(s)  is  a  state  of  FwdReq\(bmiU>,a'),  and  let  us  show  that  s  is  a 
state  of  DelRetfM{a,  a')'.  Since  in  t  there  is  a  request  arrow  in  arrows  (u/,  6.,**)  for  some  to, 
the  edge  («>,&,,*»}  must  point  toward  the  root  .  Since  (&*,«», a')  also  points  toward  the 
root  in  t,  and  since  this  root  is  unique,  this  request  arrow  must  be  in  arrows  (a,  6s  a>). 
Furthermore,  since  {&*,*•, a')  points  toward  the  root,  we  see  that  there  can  be  no  grant 
arrow  in  arrows  (a1,  and  no  request  arrow  in  arrows  (&«.*>,  a').  It  follows  by  71  that 
there  is  a  request  message  from  a  to  a!  in  the  set  messages  of  undelivered  messages 
in  s.  Therefore,  s  €  DelReq^(a,a,y . 

Third,  suppose  t  6  hj(s)  is  a  state  of  FwdGr\(a,v' ,w'),  and  let  us  show  that  s  is 
a  state  of  FwdGr*(v,w)'.  Since  there  is  a  request  arrow  in  orrow«(v\a)  in  t,  U 1  and 
.41  imply  that  v  is  contained  in  the  set  requesting #  of  requesting  processes.  Since  there 


Lb  a  grant  arrow  in  orrows(w\a )  in  t,  U 2  and  A2  imply  that  holding a  =  true  and 
laatforward 4  =  to  ini.  Therefore,  4  6  FwdGr*(v,w)\ 

Finally,  suppoee  t  €  ha(a)  ia  a  state  of  FwdGr\[btia>,a,a'),  and  let  us  show  that  s  is 
a  state  of  De/C7rj^(o',a).  Since  there  is  a  grant  arrow  in  arrows  (o',  64i4»)  in  t,  A4  implies 
that  there  is  a  grant  message  from  a'  to  a  in  the  set  messages  of  undelivered  messages 
in  s.  Therefore,  s  G  DelGr,ii(a,,ay.  □ 

Finally,  combining  the  work  of  the  last  few  section,  we  have  the  following  result. 
Let  £J  be  the  execution  module  obtained  by  renaming  the  actions  of  £3  according  to 
the  action  mapping  f\f\. 

Theorem  40:  £3  solves  E\. 

Proof:  Since  £3  satisfies  £j,  it  follows  by  Lemma  27  that  £3  satisfies  £3.  Since  ££ 
satisfies  Eit  it  follows  by  Lemma  26  that  £J  satisfies  E\.  Since  E's  is  implementable, 
Lemma  27  implies  that  £3  is  implementable.  Therefore,  £J  solves  £1.  □ 

With  this  we  have  proven  the  correctness  of  a  fully-detailed  protocol  for  resource 
allocation  in  an  asynchronous  network. 

3.4  Time  Complexity 

The  primary  concern  motivating  Schonhage’s  arbiter  is  its  time  performance.  For 
example,  Lynch  and  Fischer  consider  two  simple  resource  arbiters  in  [LF81],  allocating 
a  resource  among  n  users.  One  arbiter  is  a  process  that  simple  polls  each  user  in  round- 
robin  order,  granting  the  resource  to  each  requesting  user  in  turn.  Given  that  each  user 
uses  the  resource  for  a  bounded  amount  of  time,  the  response  time  for  this  arbiter  (the 
maximum  time  a  user  must  wait  for  the  resource)  is  O  (n)  regardless  of  the  number  of 
users  requesting  the  resource.  A  second  arbiter  is  a  binary  tree  (a  tournament  tree) 
with  the  users  at  the  leaves  of  the  tree.  Each  internal  node  of  the  tree  repeatedly 
polls  its  children  until  one  of  its  children  requests  the  resource,  at  which  point  it  stops 
and  passes  the  name  of  the  child  up  to  the  internal  node’s  parent.  The  root  of  the 
tree  actually  determines  which  user  is  granted  the  resource.  When  only  one  user  is 
requesting  the  resource  at  a  time,  this  arbiter’s  response  time  is  only  O  (logn).  In  the 
worst  case,  however,  (when  every  user  is  requesting  the  resource)  this  arbiter’s  response 
time  is  O  (nlogn).  Schonhage’s  algorithm,  in  contrast,  combines  favorable  aspects  of 
both  these  arbiters.  In  particular,  (in  the  case  that  the  graph  G  is  a  binary  tree)  the 
arbiter’s  response  time  is  O  (logn)  if  only  one  user  requests  the  resource  at  a  time,  and 
O  (n)  in  the  worst  case.  In  this  section  we  perform  the  complexity  analysis  needed  to 
make  these  claims  precise. 


For  convenience,  we  perform  our  complexity  analysis  at  the  middle  level  of  abstrac¬ 
tion,  with  the  automaton  Aj.  We  have  not  yet  introduced  the  notion  of  time  into  our 
model.  While  we  have  not  yet  decided  on  how  time  should  be  incorporated  into  our 
model,  one  alternative  is  to  assign  times  to  states  (or  equivalently  to  actions)  denoting 
the  time  at  which  an  automaton  transition  causes  the  automaton  to  enter  this  state. 
Let  us  refer  to  such  an  execution  as  a  timed  execution.  In  order  to  perform  any  time 
analysis,  it  is  necessary  to  place  bounds  on  the  time  between  automaton  transitions. 
Recall  that  all  liveness  conditions  required  of  the  automaton  At  in  the  construction 
of  E j  are  of  the  form  5  «— *  T,  meaning  that  if  Aj  enters  a  state  of  5,  then  eventually 
an  action  of  T  is  performed.  Let  us  denote  by  S  <— »  T  the  condition  that  if  Aj  enters  a 
state  s  of  5,  the  within  time  b  an  action  r  of  T  will  be  performed.  That  is,  following 
state  s  in  a  timed  execution  satisfying  S  «— ►  T  there  is  a  r-step  to  a  state  s'  such  that 
the  difference  in  times  assigned  to  s  and  s'  is  at  most  b.  Let 

BndedFwdReqi  =  /\  FwdReq\[a,  v)  FwdRtq\(a,  v) 

«,• 

BndedFwdGrt  =  FwdGr\(a,v,w)  FwdGrf(a,v,w) 

BndedRtnRes*  =  f\  RtnRe sj(u)  *— ♦  RtnRes\{ u) 

U 

Let  us  say  that  a  timed  execution  of  A%  is  b-bounded  if  it  satisfies  the  conditions 
BndedFwdReq ,,  BndedFwdGfj,  and  BndedRtnRes*.  We  define  the  response  time  in 
a  b-bounded  execution  x  of  At  to  be  a  time  r  such  that  for  all  states  s  with  request  € 
arrows (u,  a)  (where  u  is  a  user  node)  appearing  in  z,  the  differsace  in  times  assigned 
to  s  and  the  first  state  with  grant  6  arrows  (a,u)  appearing  after  s  in  x  is  less  than  r. 

Suppose  the  graph  G  has  diameter  d.  It  is  easy  to  see  that  the  response  time  for 
b-bounded  executions  of  At  is  2 bd  when  only  one  user  request  the  resource  at  a  time: 
The  request  must  travel  the  diameter  of  the  graph  to  the  root,  and  the  root  must  be 
moved  the  diameter  of  the  graph  to  the  user.  Thus,  we  have  the  following. 

Theorem  50:  If  the  diameter  of  the  graph  G  is  d,  then  the  response  time  in  b-bounded 
executions  of  Aj  in  which  at  most  one  user  requests  the  resource  at  a  time  is  2 bd. 

Conversely,  suppose  the  graph  G  has  e  edges.  We  now  show  that  the  worst-case 
response  time  (when  the  arbiter  is  heavily  loaded)  is  3be  -  6.  We  begin  with  the 
following  preliminary  lemma,  the  inductive  statement  in  the  proof  that  the  arbiter’s 
response  time  is  3be  —  6.  Given  an  edge  (v,w),  we  define  e{v,w)  to  be  the  number  of 
edges  in  the  subtree  of  v  rooted  at  w. 

Lemma  51:  Let  s  be  a  state  of  Aj  in  which  request  €  arrows  (v,  w)  and  the  edge 
(v,u/)  points  toward  the  root.  In  any  b-bounded  execution  fragment  of  Aj  from  s, 
grant  €  arrows  (w,v)  within  time  3be(v,u/)  +  b. 


Proof:  We  proceed  by  induction  on  e  =  e(v,w).  Suppose  e  —  0.  In  this  case,  w 
must  be  a  leaf,  and  hence  a  user  node.  Since  the  edge  (v,w)  points  toward  the  root, 
front  £  arrow (v,w).  Since  w  is  a  user  node,  condition  BndedRtnResx  implies  that 
front  £  arrow*  (w,  t>)  within  time  6  =  36e  +  b. 

Suppose  e  >  0  and  the  inductive  hypothesis  holds  for  numbers  of  edges  less  that  t. 
By  assumption,  the  edge  (v,w)  points  toward  the  root.  If  w  itself  is  the  root,  since 
request  £  arrows  (v,  w),  condition  BndedFwdGr j  implies  that  within  time  b  we  have 
front  £  arrows  (w,  z)  for  some  node  *.  Notice  that  if  z  =  v,  then  we  are  done, 
so  let  us  asstime  that  x  /  v.  Then  in  either  case,  regardless  of  whether  w  itself 
is  the  root,  the  edge  (w,x)  points  toward  the  root  within  time  b  for  some  node  x 
other  than  v.  Let  x  =  x,, ...,xi,v  be  the  nodes  between  x  and  v  in  the  ordering 
of  nodes  adjacent  to  w.  Let  e}  =  e(w,x,),  and  notice  that  e  >  +  1).  We 

proceed  by  induction  on  *  to  show  that  if  request  £  arrows  (v,w)  and  (w,x*)  points 
toward  the  root,  the  front  £  arrows  (w,  t/)  within  time  £yml  36(<y  +  1).  It  will  fol¬ 
low  that  front  £  arrows  (wtv)  within  time  b  +  £y,t  3 6(ey  +  1)  <  36e  +  6  of  the  time 
request  £  arrows{v,w).  The  case  of  »  =  0  is  vacuously  true.  Suppose  i  >  0  and  the 
inductive  hypothesis  holds  for  i  -  1.  Since  request  £  arrows (t/,u>),  the  edge  (w,x<) 
points  toward  the  root,  and  request  &  arrow*  (w,  x,),  condition  BndedFwdReqt  implies 
that  either  request  £  arrows[w,Zi)  or  front  £  arrowe(x,,w)  within  time  6.  In  the  case 
that  request  £  arrows (t>,w),  since  the  edge  ( w,x* )  points  toward  the  root,  the  induc¬ 
tive  hypothesis  for  e  —  1  implies  that  front  £  arrows  (x,,w)  within  time  36e,  +  b.  In 
either  case,  grant  €  arrows (zitw)  within  time  3 ie,  +  2b.  Since  request  £  arrows  (v,w) 
and  grant  £  arrows  (x,,w),  condition  BndedFwdGr j  implies  that  grant  £  arrows  (w,  x,) 
within  time  b  for  some  z,  £  {x,_i, . . . ,  ij,  v}.  The  inductive  hypothesis  for  *  -  1  implies 
that  grant  £  arrows  (w,  v)  within  time  £’~\  36(e;  +  1),  for  a  total  of  time  3 6(e,  +  1) 

as  desired.  □ 

Finally,  we  have  the  following. 

Theorem  53:  If  the  graph  G  has  e  edges,  then  the  response  time  in  any  6-bounded 
execution  of  At  is  36e  —  b. 

Proof:  Let  s  be  a  state  of  At  in  which  request  £  arrows (u,  o)  for  some  user  node  u. 
Either  front  £  arrows  (a,  u)  or  the  edge  (u,a)  points  toward  the  root.  In  the  case  that 
front  £  arrows (o,  a),  the  condition  BndedRtnResj  implies  that  grant  £  arrows(u,a) 
within  time  b.  In  either  case,  request  £  arrows  (u,  o)  and  the  edge  (u,o)  points  toward 
the  root  within  time  6.  Lemma  51  implies  that  front  £  arrows  (o,  u)  within  time 
3fre(u,  a)  +  b  =  3be  -  2b  for  a  total  of  time  3 be  -  b.  □ 

Thus,  as  claimed,  the  response  time  in  5-bounded  executions  is  linear  in  the  diameter 
of  the  network  when  the  load  on  the  arbiter  is  light,  and  linear  in  the  size  of  the  network 
when  the  load  is  heavy.  We  note  that  when  an  arbiter  node  grants  the  resource  to  an 


adjacent  node,  if  it  has  received  a  request  for  the  resource,  it  later  forwards  a  request 
in  the  direction  of  the  resource.  As  a  result,  three  messages  are  sent  over  the  edge 
to  the  adjacent  node:  the  grant  and  request  messages  sent  by  the  arbiter  node,  and  a 
grant  message  sent  to  the  arbiter  node  when  the  node  receives  the  resource.  Hence,  the 
worst  case  response  time  of  about  3 be.  If,  however,  the  arbiter  node  were  to  combine 
the  grant  and  request  messages  sent  to  the  adjacent  node,  then  only  two  messages  would 
traverse  the  edge  between  them.  We  note  that  in  this  case  the  worst  case  response  time 
is  26e.  We  have  chosen  to  separate  the  messages  in  order  to  make  the  algorithm  easier 
to  describe. 


Chapter  4 
Conclusions 


In  this  thesis  we  have  introduced  a  new  model  of  distributed  computation  in  asyn¬ 
chronous  systems.  We  find  this  model  to  be  quite  expressive,  and  find  that  the  trans¬ 
parent,  automata-theoretic  semantics  make  reasoning  about  system  behavior  relatively 
simple.  We  have  shown  how  the  strong  distinction  between  input  and  output  actions 
captures  the  game-theoretic  interplay  between  a  system  and  its  environment.  This 
distinction  has  been  found  to  be  useful  when  describing  the  interface  between  system 
components,  and  when  decomposing  a  system  into  modular  components  (see  [Blo87]). 
We  have  found  that  the  clarity  of  the  interface  between  system  components  described 
by  automata  allows  us  to  express  the  notion  of  fair  computation  quite  simply  and 
naturally.  Finally,  we  have  seen  that  automata  may  be  used  to  construct  hierarchical 
correctness  proofs  for  distributed  algorithms,  allowing  intuitive  reasoning  about  key 
high-level  ideas  behind  an  algorithm’s  behavior  to  be  incorporated  into  a  formal  proof 
of  its  correctness.  While  the  framework  developed  in  this  thesis  has  proven  to  be  quite 
useful,  there  are  a  number  of  ways  in  which  it  could  be  enhanced.  We  now  consider  a 
few  of  these  enhancements. 

First  of  all,  it  would  be  nice  to  find  a  more  compact  notation,  a  programming 
language,  for  defining  automata  than  the  precondition/effects  style  of  presentation 
used  in  this  thesis.  In  particular,  since  our  work  is  in  several  ways  similar  to  CCS, 
it  would  be  nice  to  develop  a  CCS-like  calculus  having  input-output  automata  as  its 
underlying  operational  semantics.  We  note  that  one  aspect  of  CCS  that  has  not  been 
developed  for  input-output  automata  is  a  powerful  theory  of  equational  reasoning.  We 
do  not  know  if  such  a  theory  can  be  associated  with  our  model.  Any  results  in  this 
direction  will  certainly  be  valuable,  for  they  will  allow  us  to  combine  the  transparent 
operational  semantics  of  input-output  automata  with  powerful  semantic  techniques  for 
reasoning  about  system  behavior. 

As  of  yet,  we  have  not  attempted  to  characterize  the  expressive  power  of  input- 
output  automata.  Our  feeling  that  our  model  is  generally  quite  powerful  is  the  result 
of  experience,  and  our  feeling  that  certain  aspects  of  the  model  (such  as  the  require- 


ment  that  an  automaton  be  input-enabled)  capture  important  aspects  of  asynchronous 
distributed  computation.  Bloom  has  made  some  initial  attempts  at  characterizing  the 
expressive  power  of  our  model  in  [BI086].  In  particular,  he  has  characterized  the  lan¬ 
guages  that  can  be  expressed  as  the  set  of  schedules  of  an  automaton  (resulting  from 
arbitrary  executions).  Left  uncharacterized  are  the  languages  that  can  be  expressed  as 
the  set  of  schedules  resulting  from  fair  executions.  Another  possible  characterization 
of  interest  is  the  relationship  between  the  expressive  power  of  temporal  logic  and  our 
model.  Wolper,  Vardi,  and  Sistla  show  in  [WVS83]  that  given  a  formula  in  a  particular 
extension  of  temporal  logic,  it  is  possible  to  construct  a  Buchi  automaton  accepting 
precisely  those  sequences  satisfying  the  given  formula.  It  might  be  possible  that  these 
techniques  can  be  adapted  to  prove  a  similar  result  for  input-output  automata. 

We  note  that  our  model  includes  a  single,  simple  notion  of  automaton  composition. 
In  particular,  our  composition  requires  that  automata  sharing  an  action  x  perform  x 
simultaneously  whenever  x  is  performed  by  their  composition.  The  intention  is  that  if  x 
is  an  output  action  of  A  and  an  input  action  of  B ,  then  the  simultaneous  performance 
of  x  models  communication  from  A  to  B.  We  think  of  the  performance  of  x  as  a 
computational  step  of  A  causing  B  to  be  notified  of  the  arrival  of  input.  However, 
since  two  processes  in  an  asynchronous  system  cannot  be  expected  to  perform  an  action 
simultaneously,  rather  than  complicating  our  notion  of  composition,  we  have  chosen 
to  require  that  the  output  actions  of  automata  in  a  composition  be  disjoint.  This 
has  a  number  of  effects  on  how  systems  are  modeled  with  automata.  For  instance,  to 
use  Hoare’s  example  of  a  vending  machine  (see  [Hoa85]),  suppose  that  we  construct 
automata  modeling  humans,  and  an  automaton  modeling  a  vending  machine.  Humans 
can  insert  coins  into  the  vending  machine  (output  from  humans  and  input  to  the  vending 
machine).  Since  we  require  that  the  output  actions  of  automata  in  a  composition  be 
disjoint,  if  we  compose  a  collection  of  humans  with  the  vending  machine,  each  human’s 
output  action  of  inserting  a  coin  must  be  tagged  with  an  identifier.  Thus,  the  vending 
machine  is  effectively  able  to  determine  which  human  is  inserting  a  coin,  which  is  not 
necessarily  a  realistic  model  of  this  simple  interaction.  It  might  be  interesting  to  study 
other  notions  of  composition  that  would  avoid  this  problem.  One  such  composition 
might  require  all  automata  having  x  as  an  input  action  to  synchronize  with  precisely 
one  automaton  (the  same  for  all)  having  x  as  an  output  action.  While  this  is  a  natural 
notion  of  composition,  the  semantics  of  this  composition  complicate  our  model  quite  a 
bit.  We  feel  that  one  virtue  of  our  composition  is  that,  as  a  consequence  of  Coro'.', ary  3, 
reasoning  about  the  enabling  of  an  action  in  a  composition  can  be  carried  (  ut  by 
reasoning  about  the  state  of  a  single  component.  This  has  been  found  to  be  very 
convenient  in  [LM86]. 

While  fair  computation  important  to  us,  we  have  not  made  an  explicit  study  of  the 
nature  of  fairness  in  our  model.  In  fact,  we  have  defined  only  one  of  several  possible 
notions  of  fairness  (see  Fra86  ).  We  feel  that  it  should  be  possible  to  express  many 
other  notions  of  fairness  in  our  model,  and  the  study  of  these  definitions  in  our  model 
are  of  interest  to  us. 
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However,  since  the  primary  emphasis  of  this  thesis  has  been  the  decomposition  of 
correctness  proofs,  both  hierarchically  and  modularly,  we  are  naturally  interested  in 
continuing  the  study  of  how  automata  can  be  used  in  new  techniques  of  decomposition. 
We  have  already  mentioned  the  work  of  [LS84a]  and  [LLW87).  The  authors  of  these 
papers  seem  to  be  using  a  horizontal  decomposition  different  from  any  considered  in 
our  work.  In  our  work  we  have  attempted  to  decompose  systems  into  modular  units 
that  can  be  composed  to  yield  the  desired  system.  Once  this  decomposition  has  been 
made,  each  component  can  be  examined  in  isolation,  simplifying  the  verification  pro¬ 
cess.  In  some  systems,  however,  the  system  components  are  so  heavily  interdependent 
that  no  clean  decomposition  appears  possible.  [LS84aj  and  [LLW87]  use  the  technique 
of  “projecting”  onto  one  system  component  (or  algorithm  component),  abstracting  the 
remaining  system  components  to  a  high-level  black  box,  and  reasoning  about  the  re¬ 
maining  “images.”  Notice  that  these  images  cannot  be  composed  to  yield  a  model  of 
the  system  since  each  is  a  model  of  the  complete  system.  The  work  of  [LLW87]  concerns 
how  correctness  proofs  for  each  image  can  be  combined  into  a  correctness  proof  for  the 
entire  system.  This  work  appears  to  be  quite  promising. 

Finally,  while  this  thesis  has  essentially  ignored  the  notion  of  time,  time  is  a  very 
important  part  of  modern  distributed  systems.  Timeouts,  for  instance,  are  a  crucial 
part  of  the  fault- tolerance  of  many  communication  algorithms.  Furthermore,  complex¬ 
ity  analysis  of  algorithms  requires  some  notion  of  bounds  on  processor  step  times  and 
message  delivery  times.  We  have  shown,  using  rather  ad  hoc  techniques,  how  rigorous 
reasoning  about  time  complexity  can  be  performed  n  our  model.  A  very  important 
problem  is  that  of  incorporating  time  into  our  model  more  naturally,  and  investigating 
useful  properties  about  time  that  can  be  used  to  reason  about  time  complexity  of  algo¬ 
rithms  in  our  model.  For  instance,  what  does  it  mean  to  compose  the  timed  equivalent 
of  execution  modules?  Another  important  problem  is  that  of  relating  complexity  results 
obtained  at  different  levels  of  abstraction.  In  our  example,  we  analyzed  the  complexity 
of  Schonhage’s  arbiter  at  a  level  of  abstraction  higher  than  the  fully-detailed  protocol, 
but  it  is  not  hard  to  see  how  this  complexity  result  translates  down  to  the  lower  level 
of  abstraction.  In  general,  however,  relating  time  complexities  at  different  levels  of 
abstraction  is  a  difficult  problem.  Such  problems  certainly  deserve  further  study. 
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